commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject [general] library management Was: [lang] Markup stuff on lang???
Date Sun, 25 Apr 2004 01:43:44 GMT

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


Mime
View raw message