Re: [general] library management Was: [lang] Markup stuff onlang???

[Stephen Colebourne <sc...@btopenworld.com>]

Personally I am comfortable with the current commons setup, and believe
anything else to be nigh on impractical.

I do agree with the removal of dependencies (beanutils/digester to
collections) when possible. The complaint that picking up one commons jar
requires picking up many others has some validity.

We must all remain vigilent for our components though - and kick out
excessive code before release when appropriate (lang kicked out id,
collections kicked out primitives, etc)

Stephen

----- Original Message -----
From: "Simon Kitching" <si...@ecnetwork.co.nz>
> 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!
>
> Cheers,
>
> Simon
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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