commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Dever" <jdev...@nortelnetworks.com>
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: dion@multitask.com.au [mailto:dion@multitask.com.au]
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
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


"Jeff Dever" <jdever1@nortelnetworks.com> wrote on 07/23/2002 02:06:25 AM:

> 
> Ok, I'll admit that checking in commons-logging.jar into the CVS was 
naive.
> Anyone willing to mavenize httpclient?
> 
> BTW: This falls under the 2.0 enhancement bug
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10814
> 
> 
> > >> 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>
> 

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