commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [httpclient][PATCH] Move to commons-logging
Date Tue, 23 Jul 2002 04:36:54 GMT
jsdever wrote on 07/21/2002 11:03:43 PM:

> >
> > >   2) To try to make this transisiton easier, and to make the
> > packagebuild more
> > > easily in general, I created a ./lib directory
> > >   with (some of) the jars that httpclient is dependant on.  This
> > > will have to be
> > > a discussion topic, but it is more similar to how
> > >   the jakarta site example application is done.
> >
> > Ick.... I'd much rather we move to a build process that fetches the 
> > automatically for the user. If Maven b5 when it comes out is stable, 
> > would be my preferred option. It not only does downloads of jars for 
> > user, but it can generate an ant build file if necessary, and has the
> > 'distribution' processes built in.
> With the ./lib setup, if the person running the build wants the 
> they just run ant.  If they want to use a different logging.jar for some
> reason, they just update the  If a new 
> is to be come standard in httpclient, it needs to be downloaded from 
> 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.

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.

> HttpClient only relies on a few jars anyway, and adding maven to the 
> process does add another dependancy.  I guess I'm an advocate of the 
> 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.

> Sorry for throwing in this ./lib thing in without any discussion, I just
> 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 :)

dIon Gillard, Multitask Consulting

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