commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsw.com>
Subject RE: [general] library management Was: [lang] Markup stuff on lang???
Date Sun, 25 Apr 2004 03:00:34 GMT
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.

Gary 

> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Saturday, April 24, 2004 18:44
> To: Jakarta Commons Developers List; "paulo gaspar"@flamefew.net
> Subject: [general] library management Was: [lang] Markup stuff on
lang???
> 
> 
> I'm of two minds about this.
> 
> 1) Large libraries are painful for people to deal with because a) they
are
> large in size and b) they are large in functionality.
> 
> 2) Lots of libraries are painful for people to deal with because a)
there
> are many of them, so lots to manage, and b) they desire many
> inter-dependencies.
> 
> Part of me is beginning to think the solution should be to have 1 huge
> project named Commons. This is effectively a massive JDK-like library
and
> has large releases of code with lots of interdependencies. It has a
> chaotic development environment and a lack of documentation.
> 
> This provides a suitable environment for development, new ideas, and
stops
> commons projects from becoming one tiny little build, ie)
commons-servlet.
> 
> However, after each release of Commons-huge.jar, creation of tiny,
tight
> jar releases happen.
> 
> So, after Commons-1.0's release, Commons-Collection-1.0.jar would have
> been spun off and Commons-2.0 would not have contained that jar.
> Collections-1.0 may even spin off another project, primitives,
functors,
> collections-weird or whatever, but they must do it by sending that
code
> back to Commons-2.0, not by having it become its own new project.
> 
> Commons implicitly depends on all the spawned jars, plus a few allowed
> jars, [javamail, j2ee, servlets are all that spring to mind at the
> moment], and each spawned jar may not depend on anything other than
> Commons' allowed list of jars. Importantly, a spawned jar may not
depend
> on Commons itself.
> 
> I think this is a better development process, and is working well for
me
> with my util libraries that sit on top of Commons code
> [osjava.org/genjava], but does pull the Commons community tighter
together
> and remove some of the independence.
> 
> To get to this world, we would drop the sandbox and merge it all into
one
> big Commons, then declare all released projects to be dependencies of
> Commons.
> 
> Just a mind-wander,
> 
> Hen
> 
> On Mon, 19 Apr 2004, paulo gaspar wrote:
> 
> > Sorry Matthew, I was not very clear:
> >
> > 800KB is a problem in 2 ways:
> > 1) If all libs I use are 4 time bigger than they had to be, and if I
use
> >     a lot of libs, the distros of anything I do will be huge.
Currently
> I
> >     connect mostly using a modem, and I think about this everytime I
> have
> >     to download a really simple tool and the zip has several MB,
when it
> >     could just have some hundreds KB);
> >
> > 2) Its also the granularity. I do not want to deal with stuff for
which
> >     I have other solutions. I just do not want to have all that
"noise"
> >     on docs and code around the part that I really need to use.
> >     Moreover, if I have a realy good text/markup lib for my team to
use,
> >     I do NOT like the possibility that a rookie will use the "lang"
> >     markup stuff instead of my usual lib, because that will
obviously
> >     raise the load of the team (having to learn/deal with a new bit)
> >     when doing  housekeeping on the rookie code.
> >
> > These are just reasons why a lib (or any other tool) should do one
thing
> > (and do it very well). Multiple functionality makes evaluating and
> > adopting the tool harder
> >
> > I don't even like tools that come with a mandatory properties/XML
> > mechanism. They should have just the core, a API one can use for
> > configuration and then a one or two OPTIONAL configuration
mechanisms
> > (in separate subprojects). It is easier then to adapt such tool to
> > project A or B, or framework X or Y that has its own config policy.
> >
> > I could still go on but this should be enough to make my point.
> >
> > Look, I learned this the hard way: I am in the process of breaking
> > a huge block of code that I created into smaller bits and pieces.
> > (...and I am striping the configuration mechanisms too.)
> > Argh!
> >
> >
> > Have fun,
> > Paulo Gaspar
> >
> >
> > matthew.hawthorne wrote:
> >
> > > Unknown wrote:
> > >
> > >> Does memory serve me well when I think to remember that
> > >> "commons-lang" should only
> > >> hold "core" functionality?
> > >>
> > >> I mean, if you want to grab all the things you can do with text
and
> > >> strings, we are better
> > >> served with a separated "commons-text" project, aren't we?
> > >>
> > >> I am just afraid that lang will become a > 800KB jar, like
> > >> collections already is. =:o/
> > >
> > >
> > >
> > > This has been talked about a few times.  Check out the archives.
> > >
> > > I've been reading a lot of complaints about the sizes of jar files
> > > lately.
> > > I have a hard time grasping this.  Maybe I've just been lucky
enough
> > > to work in environments where the disk space flows like wine.
> > >
> > >
---------------------------------------------------------------------
> > > 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
> >
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message