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
Date Mon, 22 Jul 2002 15:34:16 GMT

>> ever and updated in CVS.  This is a only manual process but there has to
>> 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
>> (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. :-(

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