David Graham wrote:
--- Charles Hudak <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




__________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to