commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: Why isn't Commons all one release
Date Sun, 16 Feb 2003 20:39:55 GMT

The question of macro or micro libraries seems to be a popular one.

While you represent the extreme of the macro belief, one 1 Meg+ jar or zip
that the user would download, the micro belief would want us to split the
commons packages up even more.

I imagine a lot could be learnt by the monolithic vs microkernel debates
of the linux/mach OS world, but some negatives to the macro library view:

*) Users get a huge library, they may only want a single class in that
library. When the jar file measures in the megabytes, few if any users
would bite.

*) Releases get very very difficult. A new release would have to
co-ordindate over dozens of sub-projects making a release of Commons akin
to a release of the JDK itself. This is anti to tried and tested open
source methodologies of release early, release often. Apache is however at
the slow end of this methodology due to a focus on quality.

*) Confusion to the user. While the installation is easy for the user,
they also have a mile of documentation to wade through, similar to
learning the JDK the first time, or trying to navigate the Apache
websites.

*) Pain to the user. The MacroCommons jar would contain a horde of
further dependencies, some of which Apache are not able to re-distribute
for legal reasons [JavaMail etc].

There are some major pluses though:

*) Much easier marketing to the user. Rather than having to sell each
individual library to the developer's mindset, you merely have to get them
to accept a single project. Once they've accepted and started to use it,
they'll find themselves picking up others more easily. They also have a
much easier time with dependencies as they only have to worry about
installing MacroCommons once every 12 months or so [and its 50
dependencies].
However, the market of users would be deminished. Commons would mainly be
marketed towards J2EE users.

*) Easier website. The site could be simplified a fair bit.

*) Cross-use. The Commons libraries can re-use each other without having
to decide if it is worth it. FileUpload could happily use a class from
Collections, a class from IO and a class from Lang without feeling that 3
jars for 3 classes is a heavy load.


Mainly, I would say the Commons structure is how it is because it maps
underlying communities. Commons is not one big vat of developers, but
instead a series of groups of developers. The projects themselves reflect
and dictate those groups.

This is why Lang has not yet split up, despite worries over its macro
nature, and why Jelly and Net are unlikely to join, as the developers are
not the same.

All of that said, there is a commons-combo package which builds all
commons packages into one zip/jar :) I don't believe that is published
though (yet).

Hen

On Sun, 16 Feb 2003, Robert Simmons wrote:

> As I look through the Jakarta commons package, it seems to me that
> this package should be all one release. For the developers,
> integration would be easier. For the users, they could download one
> release that had a binary of all of the components in commons. Why has
> this not been done up to now?
>
> -- Robert
>
>
>
>
> ---------------------------------------------------------------------
> 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