On 26 Apr 2004, at 00:26, Simon Kitching wrote:If you want to play with exactly this concept, check out the build.xml script in [combo]. It was designed to make a "pick the latest published release of all the constituent libraries" policy very easy to accomplish -- all you need is to update the CVS tag to pull as new releases are made. In addition, someone who wanted a different set of versions could easily override the CVS tags themselves.
On Sun, 2004-04-25 at 15:00, Gary Gregory wrote:
Or:
You release commons-all.jar with a pruner. This pruner would run just like base it's input on Clover output or manual input to create a smaller what-my-app-needs-out-of-commons.jar.
Like some other posters, I understand that people have some problems with commons being composed of a dozen separate projects. However I don't see the "one commons jar" approach as being feasable. I can't imagine how releases would be synchronized, how unit tests would be applied to the combined code, etc.
there's nothing technically unfeasible about this. (gump does this and more :)
one of the good rules we have is that each commons release should only depend on previously released code so it should just be a case of re-rolling the big jar and creating a new big-commons release each time any component was released.
There are some wrinkles yet to be worked out, and I don't have time at the moment to focus on it, but there's a starting point for someone interested. If for no other reason, consolidated Javadocs for all of commons (one of the outputs of this script) is very useful.
IMHO the main obstacle is organizational. people have enough difficulty with the current release process without adding to it. unless someone's willing to step forward and volunteer to manage the organizational side of the big commons jar (including release management) then it's not really worth wasting time on. (craig started something similar i'd guess over a year ago now but no one was really interested enough in the idea to push it forward.) i'd be happy to give a hand on the integration side but i don't cut jakarta releases any more (so i'm not willing to take this one on).I think the mechanical aspects of building a combination JAR can be dealt with. What I don't think we have in place at all is any sort of unit or system tests to ensure that version X of library FOO works with version Y of library BAR. Therefore, I'd be cautious about declaring anything about a release of [combo] other than "here is a particular combination of Commons libraries, conveniently packaged in one JAR for you."
anyone fancy stepping up?Craig
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
