Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <20031105211705.78626.qmail@web20711.mail.yahoo.com>
Date: Wed, 5 Nov 2003 13:17:05 -0800 (PST)
From: David Graham <grahamdavid1980@yahoo.com>
Subject: [OT] Re: [Math] common-math and bloated 3rd party libraries
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <3FA96663.1010706@steitz.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


--- Phil Steitz <phil@steitz.com> wrote:
> 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."  

Struts has a perfect example of why this is a bad idea.  At one point we
changed our META-INF/Manifest.mf file from the standard format to a format
that WebLogic 5 would accept.  Sometime later, another bug was filed
because Tomcat didn't like our new Manifest.mf file format because it
wasn't in the standard format.

Straying from standard practices to accomodate broken products in your
user base is a quick way to generate a lot of bug reports.  IMO, the
Windows line length limitation and WebLogic's broken jar lookup are
absolutely not reasons to change Jakarta Commons components.

David

> "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
> 


__________________________________
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