commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [Math] common-math and bloated 3rd party libraries
Date Wed, 05 Nov 2003 21:06:43 GMT
David Graham wrote:
> --- Charles Hudak <CHudak@arrowheadgrp.com> wrote:
> 
>>>Mark wrote:
>>>
>>>>Eric Pugh wrote:
>>>>This backlash against multiple commons jars is happening in a lot of
>>>
>>places.
>>
>>>>However, I think it is a bit shortsighted.  If you are in a non
>>>
>>server
>>
>>>>environment, I understand the problem, but in a server environment
>>>
>>with
>>lots
>>
>>>>of harddrive space, I don't.  Additionally, since in a server app you
>>>
>>are
>>
>>>>likely to need all thoses dependencies any way.  I think almost every
>>>
>>app
>>I
>>
>>>>work on has commons-lang, commons-loggin, and commons-collections
>>>
>>included.
>>
>>>>And then depending on what else, commons-discovery and
>>>
>>commons-beanutils
>>
>>>>show up all the time!
>>>
>>I think that this comment is a little shortsighted. We are still using
>>weblogic 5.1 and constantly have problems with the multitude of third
>>party
>>libraries that we are using. WL 5.1 does not seem to find libraries in
>>the
>>WEB-INF/lib directory, as it should, so these have to be set using the
>>classpath. Unfortunately, on Windows NT, the commandline has a size
>>limitation. Every so often, after adding another library, we are unable
>>to
>>start the server due to a "the command is too long" error. This is a
>>PITA
>>and we have been working around it for several years.
>>
>>Having to add 3 or 4 extra commons jars just because I want to use ONE
>>of
>>the libraries is lame. 
> 
> 
> I agree that packages should limit dependencies and I sympathize with your
> problems.  However, you're using a broken container on a lame desktop OS. 
> Trying to work around issues like this is *way* out of scope for commons
> packages.

I agree with your assessment of that platform; but your comment raises 
an interesting question: to what extent should commons component design 
decisions be influenced by characteristics of the user base.  My opinion 
is "lots."  "Lame and broken" as it may be, WebLogic 5 on NT has a large 
installed base => lots of potential commons users.  Similarly, WebSphere 
3 (JDK - sic - 1.2.2) and WebSphere 4 (JDK 1.3.1) are huge. Most of 
these folks have do not have the luxury of choosing their deployment 
targets and they often have limited control over their deployment 
environments. I think that it is very reasonable to try to make things 
as easy as possible for them.

I also agree with Danny's observation above that for commons-math in 
particular, the commitment in the proposal was to keep dependencies to a 
minimum.

Phil

> 
> David
> 
> 
>>I'm all for code reuse but it seems as if the
>>commons
>>developers have created alot of unnecessary dependancies between the
>>projects (maybe as a show of solidarity, who knows). This also creates
>>versioning problems. If I want to update one library, I may have to
>>update
>>several of it's dependant libraries, ad nauseum. I already deal with
>>this
>>hassle with the rapidly changing XML libraries and the fact that some
>>idiot
>>library developers insist on including dated versions of the dom and sax
>>api's in their jars.
>></rant>
>>
>>People need to realize that there are lots of legacy users out there who
>>aren't limited by only 'harddrive space'.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> 
> ---------------------------------------------------------------------
> 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