commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: [general] library management Was: [lang] Markup stuff on lang???
Date Mon, 03 May 2004 16:53:23 GMT
robert burrell donkin wrote:

> On 26 Apr 2004, at 00:26, Simon Kitching wrote:
>
>> 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.
>
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.

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?
>
> - robert
>
Craig


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message