commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject RE: [general] library management Was: [lang] Markup stuff on lang???
Date Sun, 25 Apr 2004 23:26:23 GMT
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.

My current feeling is that the existing commons release structure is
about the best that can be done. However I am open to arguments to the
contrary. As has been said by another poster, maybe we should ask the
user community what issues they currently face. But in the end the
solution adopted must also be *implementable*, which is something that
the commons developers need to decide on.

The pruner tool suggested above could possibly solve some of the
complaints. Projects could publish config-files for this pruner, eg
"minimal-collections". This config file when run through the pruner
would extract the relevant classes. There is still the drawback that the
user needs to know which set of files they want, though. And that
probably means that the end user must trawl through all the javadoc for
all the available classes anyway. So while it would resolve the
"runtime" issue of large jar files, it doesn't resolve the "design time"
issue of having a large number of classes in the commons projects. But I
don't think that is resolvable - except by providing less functionality!



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

View raw message