On Tue, 19 Mar 2002, Jeff Turner wrote:
> Date: Tue, 19 Mar 2002 15:33:28 +1100
> From: Jeff Turner <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> Subject: property naming (Re: cvs commit: jakarta-commons/digester
> build.properties.sample)
>
> On Mon, Mar 18, 2002 at 07:49:29PM -0800, Daniel Rall wrote:
> > Why not use lib.repo instead of root? Many other projects are already
> > using this variable to point to the location where Java libraries are
> > rooted.
>
> By "library repository", do you mean a directory full of random jars,
> copied or symlinked there from various projects?
>
> Is this a jar management scheme we want to encourage? :)
>
> I think we should assume a more structured, project-centric approach:
>
> base.path = ${user.home}
> jakarta.home = ${base.path}/jakarta
> proj.home = ${jakarta.home}/...
> proj.jar = ${proj.home}/...
> junit.home = ${base.path}/junit3.7
> junit.jar = ${junit.home}/junit.jar
>
> Assuming this, I think 'base.path' is better than 'lib.repo', because
> it's specifying a "base path", not a "library repository".
>
> I'm not too fussed either way. As long as there's *something* instead of
> the various hardcoded paths I've seen (/java/jars, /cvs/, d:/java/lib,
> etc). If we can get some +1's either way, I volunteer to update the
> projects.
>
The projects that inherit their build philosophy from Turbine definitely
like lib.repo, because they tend to put all the dependency JAR files in
one place.
The projects that inherit their build philosophy from Struts and Tomcat
definitely like base.path, because they assume that you have checked out
and built each of the dependent JARs, in a common base subdirectory. (For
me, for example, that is /home/craigmcc/Jakarta, with a subdirectory under
it for each CVS repository I care about, and I maintain the results of
"ant dist" builds in each case for the code that I currently develop
against).
The defaults from Digester have inherited the latter philosophy (because
of where the code came from), so base.path is a better name for
build.properties.sample in this case.
NOTE: This isn't a value judgement on which philosophy is better -- both
are equally valid, but consistency within a particular philosophy is even
more important than choosing one or the other.
>
> --Jeff
Craig
>
> > [EMAIL PROTECTED] writes:
> >
> > > jefft 02/03/18 17:30:59
> > >
> > > Modified: digester build.properties.sample
> > > Log:
> > > More properties parametrization
> > >
> > > Revision Changes Path
> > > 1.5 +5 -3 jakarta-commons/digester/build.properties.sample
> > >
> > > Index: build.properties.sample
> > > ===================================================================
> > > RCS file: /home/cvs/jakarta-commons/digester/build.properties.sample,v
> > > retrieving revision 1.4
> > > retrieving revision 1.5
> > > diff -u -r1.4 -r1.5
> > > --- build.properties.sample 27 Feb 2002 00:50:33 -0000 1.4
> > > +++ build.properties.sample 19 Mar 2002 01:30:59 -0000 1.5
> > > @@ -1,5 +1,7 @@
> > > -jaxp.jaxp.jar=/java/jars/jaxp.jar
> > > -jaxp.parser.jar=/java/jars/crimson.jar
> > > +root=/java/jars
> > > +jaxp.home=${root}
> > > +jaxp.jaxp.jar=${jaxp.home}/jaxp.jar
> > > +jaxp.parser.jar=${jaxp.home}/crimson.jar
> > >
> > > # Commons projects -- correct if 'ant dist' is run on each project in the
> > > # default CVS directory layout
> > > @@ -11,4 +13,4 @@
> > > commons-logging.jar=${commons-logging.home}/commons-logging.jar
> > >
> > > # junit.jar - JUnit 3.7+ Classpath
> > > -junit.jar=/java/jars/junit.jar
> > > +junit.jar=${root}/junit.jar
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
