Orbit is now ready for prime-time. However don't ask us to put in Orbit your favorite jar because Orbit is *not* a super general repository. As per the project charter you will only find in here the libraries that other eclipse projects need. In fact the creation of orbit stemmed from the problem experienced in Callisto where each projects had their own copy of common.logging and the like which created various problems.
So to summarize, if you are an eclipse project using third party libraries and you want to maintain your libraries in a central place, then Orbit is for you (platform, wtp, tptp and a few other projects already do that).
- "so no GPL or LGPL is allowed.": Of course, this is true of eclipse in general because of license compatibility issues.
- "and the bundles have a date qualifier (which then changes between the builds, even if the actual version of Xerces and the codebase remains the same)". Wrong. Orbit uses the same practice than the eclipse SDK when it comes to managing qualifiers. The qualifier is generated from the CVS tag and the output will not change from one build to another if the content of the project has not changed. For example, the javax.servlet bundle in orbit S200703161546 , is the same than javax.servlet in orbit S200702082257.
2 comments:
Thanks for the clarifications. I'll make a note on the EZ post.
I've added a new post on the subject at EclipseZone.
Note that the qualifier of the bundle does change even if the version of the underlying library might e.g. the Batik-Swing example that I put in the post.
Having said that, there's sometimes good reasons for doing this (e.g. the manifest entries need to be updated) that is separate from the version of the file.
Even so, the URL for downloading the bundle is different in your javax.servlet case even though they are binary identical. This prevents any kind of decent caching by e.g. internal build systems.
Post a Comment