[general] library management Was: [lang] Markup stuff on lang???

[Henri Yandell <ba...@generationjava.com>]

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

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

[robert burrell donkin <ro...@blueyonder.co.uk>]

On 25 Apr 2004, at 17:46, Phil Steitz wrote:
> matthew.hawthorne wrote:
>> Henri Yandell wrote:

<snip>

> I don't know the answer to this, but I agree that we have never 
> reached anything close to a consensus on this subject and I suspect 
> that it really does come down to user preference and characteristics 
> of the user environment.  We should take discussion of this topic to 
> the user list.
>> If commons is guilty of anything, it's probably just being a little 
>> loose with inter-project
>> dependencies.  The digester-collections situation which has been 
>> discussed lately is
>> a perfect example where cut-and-paste would have probably been a 
>> better solution.
>
> Another hard problem.  Cut-and-paste is appealing, but is essentially 
> forking and has some drawbacks, including:
>
> 1) If you care about tests and documentation, you need to hack in and 
> maintain the associated tests and docs as well
> 2) If you decide at a later time that there is more in the source 
> package that you want / need, you may be SOL
> 3) Forking / fragmentation fragments eyeballs

AIUI ArrayStack is one of craig's. when it's a single class which is 
well tested and not very changeable then with hindsight, it would have 
been better to retain the code inside digester. i now use a lot of 
private nested classes and this would be an example of a time when i 
think that it would be appropriate to use one to prevent the 
implementation becoming part of the digester API.

a bigger mistake was not spotting the use of the class in the public 
API of beanutils before it was too late :(

- robert


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

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

[Phil Steitz <ph...@steitz.com>]

matthew.hawthorne wrote:
> Henri Yandell wrote:
> 
>> 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.
> 
> 
> 
> With the proposed system, I'm pessimistic that even a 1.0 release would 
> ever happen.
> The required amount of coordination between projects just seems impossible.

I agree.  Another consequence of code fragmentation is test and 
documentation consistency.  Pulling things apart and recombining would 
make maintenance of tests and documentation a major PITA.
> 
> It it an interesting idea, but what would happen the first time that I 
> need something in
> the commons-collections CVS HEAD?  I'm confused how the development of 
> individual
> commons projects would coincide with the politics surrounding the 
> communal releases,
> which basically just points back to my original statement.
> 
> A part of the problem that it seems you're trying to solve is the 
> infamous "too many jars".
> Maybe I'm just being stubborn, but I don't feel that I've ever heard a 
> coherent
> argument as to why this is an actual problem and not just somebody's 
> preference.

I don't know the answer to this, but I agree that we have never reached 
anything close to a consensus on this subject and I suspect that it really 
does come down to user preference and characteristics of the user 
environment.  We should take discussion of this topic to the user list.
> 
> If commons is guilty of anything, it's probably just being a little 
> loose with inter-project
> dependencies.  The digester-collections situation which has been 
> discussed lately is
> a perfect example where cut-and-paste would have probably been a better 
> solution.

Another hard problem.  Cut-and-paste is appealing, but is essentially 
forking and has some drawbacks, including:

1) If you care about tests and documentation, you need to hack in and 
maintain the associated tests and docs as well
2) If you decide at a later time that there is more in the source package 
that you want / need, you may be SOL
3) Forking / fragmentation fragments eyeballs

The last item above points to a whole range of community issues that makes 
me think that we are better off defining and maintaining a stable set of 
reasonably scoped components.  While some Commons components are indeed 
"large," it is still possible for both developers and users to learn their 
way around even the big ones (e.g. [collections]). This has lots of 
benefits that we (both users and developers) would lose if the components 
effectively lost their individual identities.  Obviously, the hard part is 
in defining "reasonable scope," and managing the size-dependencies 
tradeoff, but I don't think that the answer is to throw in the towel and 
drop the idea of individual Commons components.

Just my HO.  Could be I am missing Hen's point.

Phil
> 
> How does everyone else feel?  Does commons have an actual problem with 
> releases
> and packaging?
> 
> 
> ---------------------------------------------------------------------
> 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

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

["matthew.hawthorne" <ma...@apache.org>]

Henri Yandell wrote:
> 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.


With the proposed system, I'm pessimistic that even a 1.0 release would 
ever happen.
The required amount of coordination between projects just seems impossible.

It it an interesting idea, but what would happen the first time that I 
need something in
the commons-collections CVS HEAD?  I'm confused how the development of 
individual
commons projects would coincide with the politics surrounding the 
communal releases,
which basically just points back to my original statement.

A part of the problem that it seems you're trying to solve is the 
infamous "too many jars".
Maybe I'm just being stubborn, but I don't feel that I've ever heard a 
coherent
argument as to why this is an actual problem and not just somebody's 
preference.

If commons is guilty of anything, it's probably just being a little 
loose with inter-project
dependencies.  The digester-collections situation which has been 
discussed lately is
a perfect example where cut-and-paste would have probably been a better 
solution.

How does everyone else feel?  Does commons have an actual problem with 
releases
and packaging?


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