commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [general] library management
Date Mon, 03 May 2004 23:24:12 GMT
Simon Kitching wrote:

>On Tue, 2004-05-04 at 10:45, Craig McClanahan wrote:
>>Simon Kitching wrote:
>>>That's my concern. If collections releases 3.0, we can't just roll a new
>>>"commons-all" jar without testing that projects like beanutils or
>>>digester work with this new collections release. But how on earth do we
>>>do that? It seems to me that the unit tests for every project that
>>>depends upon the newly released project would need to be run - at the
>>>very least - in order to provide any guarantees that the "commons-all"
>>>release is stable. Does the "combo" project do this? If not, is it
>>>really the kind of release that Jakarta wants to put its name to?
>>I'd worry about this more if I believed that projects that ship multiple 
>>commons JARs today (like Tomcat or Struts) do any interoperability 
>>testing beyond making sure that their own uses of the underlying 
>>libraries was successful.  It doesn't seem unreasonable to offer a 
>>convenience package whose contents is a specifically listed set of 
>>commons JARs ... the functional result of using this JAR should match 
>>the functional result of using all the individual JAR files themselves.
>>If we're still concerned about compatibility testing, another way to 
>>look at [combo] is a tool for people to build their own custom 
>>combinations, rather than something we use to ship a combined package 
>If combo is just something that people working on tomcat, geronimo, etc
>check out from CVS then use to build a custom jar that sounds fine to
>If combo is used to generate a bunch of custom jars, eg
>"commons-all.jar", that are directly downloadable via a link on the
>jakarta commons page, then I am concerned that it would damage Jakarta's
>image. Publishing binaries that may crash when run with some kind of
>"incompatible classes" error message doesn't look good, no matter what
>disclaimers are on the link. And if the disclaimers are too severe, then
>who will use these jars anyway?
I wouldn't see us publishing anything more than just one combo JAR that 
was always the latest released version of every commons proper package 
(i.e. not sandbox).  Anyone who wanted to subset, or pick different 
version combinations, can do it with properties files and a rebuild.

>>>Gary Gregory's "pruner" suggestion seems like a possible way forward to
>>>me. The pruner could takes a configuration file that specifies a set of
>>>classes. It would then run against a set of jars and extract the
>>>specified classes plus all their dependencies into a new jar file.
>>>Jakarta could publish a set of configuration files for various purposes.
>>>Running the tool against a single jar, or against a project's jars + its
>>>officially-supported dependencies would guarantee a functioning result.
>>>Running the tool against the complete set of latest releases of all
>>>projects might not result in a jar file that is valid (eg collections
>>>3.0 + classes that depend on collections-2.x). The one issue it does
>>>*not* address is generation of javadoc for the resulting jar. However
>>>such a tool should be simple for users to use. We *could* potentially
>>>automate its use to build a set of customised releases, but I would
>>>certainly not be in favour of this for the "cross-project" bundles, due
>>>to the inability to run the necessary unit tests as described above. 
>>>What do people think about the "pruner" suggestion?
>>I can see how pruner might be useful for static dependencies (i.e. 
>>import statements).  What do you do about dynamic dependencies (for 
>>example, a class loaded by ClassLoader.loadClass() whose name is only 
>>known because it's in a configuration file)?  And how does this do any 
>>better at dealing with inter-library compatibility testing?  
>>Compiles-clean isn't really good enough -- and Gump can already tell us 
>Dynamic dependencies just need to be specified in the configuration
>file. As an example, in Digester the PluginCreateRule is not directly
>referenced by the Digester class. So if the config file just specifies
>"org.apache.commons.Digester" then the PluginCreateRule will not be in
>the resulting jar. If the config file specifies PluginCreateRule as
>well, then not only that Rule but all the necessary supporting classes
>(most of the rest of the plugins module) gets pulled in too. The person
>writing the config file needs to decide what they do and do not want
>included - which is the point, really.
>Re inter-library compatibility: 
>If you gather together digester.jar + all its official dependencies
>(beanutils 1.6.1, collections 2.1) then run the pruner you are
>guaranteed a good resulting jar. We could even automate this process (eg
>via a maven plugin), because Jakarta would be publishing a proper subset
>of libraries that have been tested together.
>If you gather together digester.jar + the *latest* releases of
>beanutils, collections, etc. and run the pruner then you are *not*
>guaranteed a good resulting jar. I would recommend that Jakarta never
>publish such jars pre-built. But I see no problems with publishing the
>pruner configuration files that allow people to build such custom jars
>very easily.
>In the case of Collections, which has no dependencies, things are even
>easier. Rather than mess around with the ant buildfiles to generate a
>bunch of different distribution targets, just create a set of pruner
>config files which can be run against the complete collections jar
>(automatically or manually) to generate the simpler kind of
>distributions that people have been asking for. [except that propably
>also want matching pruned javadoc, which I don't have an answer for at
>the moment].
>NB: I'm not heavily pushing the pruner concept. It just seemed an
>interesting idea I thought might be worth raising for discussion..
That makes sense -- thanks.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message