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>
Date: Mon, 22 Jul 2002 08:54:48 -0700 (PDT)
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: RE: [httpclient][PATCH] Move to commons-logging
In-Reply-To: <3549C09B853DD5119B540002A52CDD34043A651F@zcard0ka.ca.nortel.com>
Message-ID: <20020722084303.S34231-100000@icarus.apache.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Mon, 22 Jul 2002, Jeff Dever wrote:

> Date: Mon, 22 Jul 2002 11:34:16 -0400
> From: Jeff Dever <jdever1@nortelnetworks.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: RE: [httpclient][PATCH] Move to commons-logging
>
>
> >> ever and updated in CVS.  This is a only manual process but there has to
> be
> >> some manual confirmation that the library will work anyway.
> >Not necessarily. There's no real need for a manual process to be in place.
>
> It seems a little dangerous for some automatic process to grab the latest
> and greatest jar for some dependant library without some human reading the
> changelog and ensuring that this new library is a "good thing".
>
> >If we are going to keep storing jars in CVS we should tag them with a
> >version number. At the moment I can't tell from the jar whether it's 1.0
> >some dev version or a personal hacked copy.
>
> Yes, its definately a "bad thing" not knowing what verison of a jar.  I was
> going to use a softlink, but realize that not everyone runs unix (for some
> unknown reason) and didn't know how that would affect others.  In short I
> just stuffed it in there as a hack.
>
> >> as possible approach, and the ./lib setup is certainly simple.
> >Maven generates an ant build file in b5 so that a plain ant build would be
> >possible for anyone without maven.
>
> Cool.  Maven does sound good.
>
> >> wanted to make the commons-logging as transparent as possible.  I'm not
> >> against using somthing else, as long as it matches the goals for
> httpclient
> >> (whatever those are!)
> >Cool, I'm just not a fan of dependent jar files in CVS as every project
> >duplicates the other and my hd fills up :)
>
> I hear ya.  As long as we can ensure that everyone is using the "right"
> version of the library, thats good.  It is still likely that you will have
> few different versions of jars for different applications needs. :-(
>
>

And there is the real problem, which is the reason I don't like JAR files
checked into CVS either.  (Disk space isn't expensive enough to be a
deterrent any more :-)

Let's assume that I want to build a single app that uses two different
commons packages (A and B) that both depend on a third one (S).  In the
runtime environment of my app, all three are going to be in the same class
loader, so there can obviously only be one copy of S.

The challenge comes when A and B each depend on different versions of S.
I don't find out about problems (say, incompatible method signatures due
to changes between S1 and S2) until I'm doing integration testing (and
only then if my test suite happens to include coverage for the combination
in question).

I'd really like the compiler to help me catch things like this, by forcing
*my* compilations of A and B to use a specific copy of S, no matter what
the A and B project documentation declares to be the required versions.

In non-Mavenized builds like BeanUtils and Digester, I manage this through
a shared "${user.home}/build.properties" file that declares which version
of S's jar files should be used.  (This relies on using the same property
name in each build script, which is generally true for Commons projects
but not always true elsewhere.)

Fortunately, Jason just added similar functionality to Maven, so Mavenized
apps will be able to do the same sort of "local override" configuration.
So, there is now even less reason for projects to continue to check JAR
files into CVS.

Craig


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