On Mon, Mar 18, 2002 at 08:41:22PM -0800, Craig R. McClanahan wrote:
>
> On Tue, 19 Mar 2002, Jeff Turner wrote:
>
> > 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.
...
> > 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
...
>
> 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.
Thanks for the explanation.
> 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.
I rather thought Jakarta-commons had it's own internal consistency to
defend, irrespective of where a project originated.
No need for flames about such a trivial issue. Anyone who cares, please
vote:
[ ] Standardize on the project-centric 'base.path' approach.
[ ] Standardize on the repository-centric 'lib.repo' approach.
[ ] Leave as is.
--Jeff
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
