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.
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).
anyone fancy stepping up?
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
