commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Dever" <>
Subject RE: [httpclient][PATCH] Move to commons-logging - mavenize httpcl ient
Date Mon, 22 Jul 2002 17:28:33 GMT
I added Craig's comments to the bug for tracking purposes.

-----Original Message-----
From: []
Sent: Monday, July 22, 2002 1:12 PM
To: Jakarta Commons Developers List
Subject: RE: [httpclient][PATCH] Move to commons-logging - mavenize
httpcl ient

I'm happy to do it once Maven b5 is released and stable....
dIon Gillard, Multitask Consulting

"Jeff Dever" <> wrote on 07/23/2002 02:06:25 AM:

> Ok, I'll admit that checking in commons-logging.jar into the CVS was 
> Anyone willing to mavenize httpclient?
> BTW: This falls under the 2.0 enhancement bug
> > >> ever and updated in CVS.  This is a only manual process but there 
> 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 
> > and greatest jar for some dependant library without some human reading 
> > 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 
> > >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 
> > 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 
> be
> > >possible for anyone without maven.
> >
> > Cool.  Maven does sound good.
> >
> > >> wanted to make the commons-logging as transparent as possible.  I'm 
> > >> 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 
> > >duplicates the other and my hd fills up :)
> >
> > I hear ya.  As long as we can ensure that everyone is using the 
> > version of the library, thats good.  It is still likely that you will 
> > few different versions of jars for different applications needs. :-(
> >
> >
> And there is the real problem, which is the reason I don't like JAR 
> 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 
> 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 
> in question).
> I'd really like the compiler to help me catch things like this, by 
> *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 
> a shared "${user.home}/" file that declares which 
> of S's jar files should be used.  (This relies on using the same 
> 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 
> 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:
> <>
> For additional commands, e-mail:
> <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message