Andrew Overholt and Tom Fitzsimmons sat with a guy from Alfresco (Lee Faus) last Friday in the FUDCon hackfests. Mainly they were doing a code review with him to see what he has to do to get Alfresco packaged for Fedora. It was a great effort, and possibly enlightening for everyone as to the scope of the problem ahead of us to get Java ISVs packaged in Fedora.
Andrew, Tom -- where there any insights, lessons, ideas, or other outfalls from that work with Lee?
Two specific areas of interest are:
* Tips, ideas, or plans for Java packaging ==> target wiki/Packaging/Java * ISV-specific lessons, tips, etc. ==> target wiki/SIGs/ISV
I'm asking on this list because I think a brain dump from both of you here would give good exposure. I'm ready to glean content to make the above wiki updates. :)
- Karsten
Hi,
* Karsten 'quaid' Wade kwade@redhat.com [2008-06-25 10:54]:
Andrew, Tom -- where there any insights, lessons, ideas, or other outfalls from that work with Lee?
Well, the process we went through was quite simple, actually: list the software they were using (in this case it was find all the JARs), determine where it came from, and see if it was already packaged. Moving applications onto newer version of libraries so that we're only ever shipping one will always be a challenge for ISVs since they're often using some version that they imported into their tree at some point in the past. This is one obvious difference between ISV packaging and distribution packaging. If we get more ISVs actually developing _on_ Fedora and more up-to-date dependencies, we may be able to help bring everyone's dependencies forward.
- ISV-specific lessons, tips, etc. ==> target wiki/SIGs/ISV
I really wish we had video-taped Tom and Lee talking. At the beginning of the conversation Lee was unaware of the benefits of being a part of the distribution and was wary of relying on dependencies outside of their direct control; by the end of the conversation, he was fully in agreement of the benefits of being a part of the distribution :) Tom: perhaps you could write up some of the common arguments by ISVs and the Free Software / distribution POV for each of them?
Andrew
Andrew Overholt overholt@redhat.com writes:
Hi,
- Karsten 'quaid' Wade kwade@redhat.com [2008-06-25 10:54]:
Andrew, Tom -- where there any insights, lessons, ideas, or other outfalls from that work with Lee?
Well, the process we went through was quite simple, actually: list the software they were using (in this case it was find all the JARs), determine where it came from, and see if it was already packaged. Moving applications onto newer version of libraries so that we're only ever shipping one will always be a challenge for ISVs since they're often using some version that they imported into their tree at some point in the past. This is one obvious difference between ISV packaging and distribution packaging. If we get more ISVs actually developing _on_ Fedora and more up-to-date dependencies, we may be able to help bring everyone's dependencies forward.
- ISV-specific lessons, tips, etc. ==> target wiki/SIGs/ISV
I really wish we had video-taped Tom and Lee talking. At the beginning of the conversation Lee was unaware of the benefits of being a part of the distribution and was wary of relying on dependencies outside of their direct control; by the end of the conversation, he was fully in agreement of the benefits of being a part of the distribution :) Tom: perhaps you could write up some of the common arguments by ISVs and the Free Software / distribution POV for each of them?
Here's a draft document:
https://fedoraproject.org/wiki/FedoraForISVs
I linked to it from the ISV SIG page:
https://fedoraproject.org/wiki/SIGs/ISV#Resources_for_ISVs
Tom
Thomas Fitzsimmons wrote:
Andrew Overholt overholt@redhat.com writes: Here's a draft document:
You could also list download counting/tracking as a "loss". If an ISV provides a tar-based distribution from their website, they can track counts and/or emails. This may be important for their marketing department.
One other item, and perhaps this is covered some place else, but are there accepted standards for aggregate packages (e.g. war, ear, rar) files? For Java, this seems like more then just "Unity with Windows release process"
-- bk
* Bryan Kearney bkearney@redhat.com [2008-07-07 08:06]:
One other item, and perhaps this is covered some place else, but are there accepted standards for aggregate packages (e.g. war, ear, rar) files? For Java, this seems like more then just "Unity with Windows release process"
Last I heard a few people were working on guidelines for web apps including J2EE, etc. apps. Check through PackagingDrafts/ on the wiki.
Andrew
Bryan Kearney bkearney@redhat.com writes:
Thomas Fitzsimmons wrote:
Andrew Overholt overholt@redhat.com writes: Here's a draft document:
You could also list download counting/tracking as a "loss". If an ISV provides a tar-based distribution from their website, they can track counts and/or emails. This may be important for their marketing department.
Good point. Wiki updated.
One other item, and perhaps this is covered some place else, but are there accepted standards for aggregate packages (e.g. war, ear, rar) files? For Java, this seems like more then just "Unity with Windows release process"
https://fedoraproject.org/wiki/PackagingDrafts/JavaWebApps
Tom
Andrew Overholt wrote:
difference between ISV packaging and distribution packaging. If we get more ISVs actually developing _on_ Fedora and more up-to-date dependencies, we may be able to help bring everyone's dependencies forward.
I wasn't at FUDCon, so I don't know if any of this was discussed, but...
The biggest issue with that, I think, is that anyone using Maven is already completely outside of the normal "ask the distro for a dependency" way of doing things; doing maven-based development on fedora will still always end up using maven for resolving dependencies. :(
Not to mention when you get into all of the OSGI stuff where foo uses bar 1.x and baz uses incompatible-bar 2.9.x and it does classloading to allow them to be available simultaneously.
At some level it seems like some kind of fundamental tools need to be designed to tell maven to prefer system versions over specific versioned-dependencies, run unit tests against them, etc., but that's a huge amount of work.
* Benjamin Reed ranger@opennms.org [2008-07-04 15:30]:
The biggest issue with that, I think, is that anyone using Maven is already completely outside of the normal "ask the distro for a dependency" way of doing things; doing maven-based development on fedora will still always end up using maven for resolving dependencies. :(
Deepak Bhole has done some great work on the maven package in Fedora which one can use to build _only_ from other stuff in the distro and never touch the maven repos.
Not to mention when you get into all of the OSGI stuff where foo uses bar 1.x and baz uses incompatible-bar 2.9.x and it does classloading to allow them to be available simultaneously.
It's the same root issue, though: either people move to new versions -- the one we ship -- or they maintain compat- packages. The former is obviously preferred :)
Andrew
java-devel@lists.fedoraproject.org
-
Andrew Overholt -
Benjamin Reed -
Bryan Kearney -
Karsten Wade -
Thomas Fitzsimmons