You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by je...@apache.org on 2002/03/19 02:30:59 UTC
cvs commit: jakarta-commons/digester build.properties.sample
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Martin Cooper <ma...@tumbleweed.com>.
> [+1] Standardize on the project-centric 'base.path' approach.
> [ ] Standardize on the repository-centric 'lib.repo' approach.
> [ ] Leave as is.
(I'm expressing a personal preference, not declaring that it's "better".)
--
Martin Cooper
----- Original Message -----
From: "Jeff Turner" <je...@socialchange.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, March 18, 2002 8:59 PM
Subject: Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
> 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Jeff Turner <je...@socialchange.net.au>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jeff Turner <je...@socialchange.net.au> writes:
>> Yes. Practice has shown me that it works extremely well. In fact,
>> it's a time honored tradition, with the historical precedent dating
>> back the beginnings of Unix. See /lib, /usr/lib, and /usr/local/lib
>> on your favorite Unix or Linux box. Let's learn from history.
>
> I agree that a /usr/lib repository mechanism is much better than the
> project-centric approach, IF it's done properly. Specifically, if
> version management is taken very seriously. Otherwise you end up with a
> directory full of jars from who-knows-where.
>
> If Maven has solved the versioning problem, then I'm keen to use it.
Maven does a reasonable job of solving the versioning problem through
its dependency list. Currently, only one person (the Maven repository
manager) has to futz with the JARs, once. Everyone else just uses
Maven to pull the JARs and build.
> Until then, is there any reason we can't accomodate both systems? Heck,
> they're just build properties ;)
Yes, let's continue this discussion and figure out what the common
ground is. I'm willing to work on this for all the packages I use
(which is quite a few, looking at Catalina's dependency tree alone ;).
>> I am fussy. I'm so sick of building these projects where I have to
>> set a million build variables instead of just one or two to produce a
>> JAR (which I generally just need as a dependency for some other
>> project).
>
> Absolutely. Every time I get a chance to work on a Commons project, I
> first spend half an hour fiddling with dependencies to get it building.
FWIW, I generally don't have to do this with lib.repo-style projects.
In 85% of the cases, I simply pull from version control, cd in the new
directory, and type `ant`, and grab the JAR.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Jeff Turner <je...@socialchange.net.au>.
On Tue, Mar 19, 2002 at 09:14:53AM -0800, Daniel Rall wrote:
> Jeff Turner <je...@socialchange.net.au> writes:
>
> > 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?
>
> Exactly. Preferably with version numbers in their file names. ;-)
there's the catch...
> > Is this a jar management scheme we want to encourage? :)
>
> Yes. Practice has shown me that it works extremely well. In fact,
> it's a time honored tradition, with the historical precedent dating
> back the beginnings of Unix. See /lib, /usr/lib, and /usr/local/lib
> on your favorite Unix or Linux box. Let's learn from history.
I agree that a /usr/lib repository mechanism is much better than the
project-centric approach, IF it's done properly. Specifically, if
version management is taken very seriously. Otherwise you end up with a
directory full of jars from who-knows-where.
If Maven has solved the versioning problem, then I'm keen to use it.
Until then, is there any reason we can't accomodate both systems? Heck,
they're just build properties ;)
> > 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
>
> This structure only works efficiently when you've checked out or
> downloaded the dependent packages in the exact manner that the build
> file's author did.
It works very efficiently if you accept the premises it's based on, that
users have either:
- checked stuff out from CVS and built a distribution (ant dist).
- downloaded a binary distribution (the standard Jakarta software
distribution mechanism).
If, rather, you're assuming a Maven-managed jar repository, then it's
not optimal.
I claim that most Jakarta-commons users are not using Maven (yet) and
therefore those assumptions are valid. Agree? But it's not an either/or
situation. You're more than welcome to add properties to accomodate a
more advanced, repository-centric approach.
> > 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.
>
> I am fussy. I'm so sick of building these projects where I have to
> set a million build variables instead of just one or two to produce a
> JAR (which I generally just need as a dependency for some other
> project).
Absolutely. Every time I get a chance to work on a Commons project, I
first spend half an hour fiddling with dependencies to get it building.
--Jeff
> - Dan
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jeff Turner <je...@socialchange.net.au> writes:
> 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?
Exactly. Preferably with version numbers in their file names. ;-)
> Is this a jar management scheme we want to encourage? :)
Yes. Practice has shown me that it works extremely well. In fact,
it's a time honored tradition, with the historical precedent dating
back the beginnings of Unix. See /lib, /usr/lib, and /usr/local/lib
on your favorite Unix or Linux box. Let's learn from history.
> 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
This structure only works efficiently when you've checked out or
downloaded the dependent packages in the exact manner that the build
file's author did. If you vary from the One True Way assumed by the
build file, you end up having to unnecessarily waste your time setting
up a ton of build variables.
> 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.
I am fussy. I'm so sick of building these projects where I have to
set a million build variables instead of just one or two to produce a
JAR (which I generally just need as a dependency for some other
project).
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> We're trying to encourage the use of a central repository of JARs.
> Having the one repository makes things like automatically downloading
> JARs easier for those who are interested in only developing or fixing
> the single package they are interested in.
>
> I'm only pointing out that we work in a similiar fashion in that we like
> to have everything checked out, that's generally how I work at any rate.
Indeed, I work in the same fashion. I learn how to build every
Jakarta package I use -- in my own work, and at CollabNet -- from
source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digesterbuild.properties.sample)
Posted by Juozas Baliuka <ba...@centras.lt>.
<snip>
> So other than space issues and duplication of JARs everywhere there is
> the issue of using the JAR that was produced by the project itself. So
> if Turbine puts some JARs in the central repository they are guaranteed
> to be the JARs produced by Turbine and not some tweaked JAR that was
> placed in CVS.
>
> It's definitely easier to check everything into CVS but I believe the
> central repository of JARs theory will win out :-)
>
Yes it is good idea.
I think It is better to have "readme" in lib, or "autodownload" in build
script if some target
need this JAR.
<snip>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henri Yandell <ba...@generationjava.com> writes:
> I agree fully. Jar repository will be the way to go. Now, my dumb-user
> question is: Maven or JJAR. What's the url for Maven? (and as an outside
> Turbine person, is it a nice separate component?)
Maven is completely separate from Turbine. Pete Kazimer has done a
great job producing some very useful initial documentation, which is
all published to the web site (and created by Maven itself):
http://jakarta.apache.org/turbine/maven/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by Jason van Zyl <jv...@zenplex.com>.
On Tue, 2002-03-19 at 11:37, Henri Yandell wrote:
>
> I agree fully. Jar repository will be the way to go. Now, my dumb-user
> question is: Maven or JJAR. What's the url for Maven? (and as an outside
> Turbine person, is it a nice separate component?)
Maven: http://jakarta.apache.org/turbine/maven/
What JJar does is a small part of what Maven does. JJar basically grabs
JARs based on dependency descriptor. Maven will grab JARs with one of
its tasks based on a project descriptor with the dependencies listed
within. The JAR retrieval supports the use of a proxy and uses
timestamps so that only what is required is brought down.
It has no dependencies on Turbine itself. It has a dependency on an
XML->Bean mapper that is in the jakarta-turbine-stratum repository
but I am tossing that in favour of betwixt in the commons sandbox.
I have built ~20 projects with Maven now and people have tried with
various projects and in the majority of cases it's been a success. Maven
is actually used to build the graph2 component in the sandbox and all
the Turbine projects have project descriptor. David Taylor is going to
try with Jetspeed, Geir is going to try with Velocity and I'm going make
a descriptor for BCEL and XMLRPC. Any project I have contact with I'm
going to try to use Maven.
> On 19 Mar 2002, Jason van Zyl wrote:
>
> > Using something like JJAR or Maven (which has auto JAR downloading
> > feature) allows you to use a single set of JAR files for building all
> > your projects instead of having each project store JARs in CVS.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by Henri Yandell <ba...@generationjava.com>.
I agree fully. Jar repository will be the way to go. Now, my dumb-user
question is: Maven or JJAR. What's the url for Maven? (and as an outside
Turbine person, is it a nice separate component?)
On 19 Mar 2002, Jason van Zyl wrote:
> Using something like JJAR or Maven (which has auto JAR downloading
> feature) allows you to use a single set of JAR files for building all
> your projects instead of having each project store JARs in CVS.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by Jason van Zyl <jv...@zenplex.com>.
On Tue, 2002-03-19 at 10:59, Henri Yandell wrote:
>
> I've been playing with it to use for work too. Trying to figure out what
> advantages JJAR has over just using cvs and ant-cvs tasks.
Using something like JJAR or Maven (which has auto JAR downloading
feature) allows you to use a single set of JAR files for building all
your projects instead of having each project store JARs in CVS.
Maven will currently see if you have the required JARs for building and
brings them down from a central repository and stores them in your local
repository for use. It's not fool proof yet, in Turbine land we battled
with Maven yesterday to get all the distributions out the door but we
did it and it worked and all of used the same set of JARs.
So other than space issues and duplication of JARs everywhere there is
the issue of using the JAR that was produced by the project itself. So
if Turbine puts some JARs in the central repository they are guaranteed
to be the JARs produced by Turbine and not some tweaked JAR that was
placed in CVS.
It's definitely easier to check everything into CVS but I believe the
central repository of JARs theory will win out :-)
> On Tue, 19 Mar 2002, Tomasz Pik wrote:
>
> > Jason van Zyl wrote:
> >
> > What about Commons-Sandbox JJar Component?
> > I use a little modified version of this tool and I think this is a very
> > good solution for 'continous integration' and managing of differen
> > versions of libraries at all.
> >
> > BTW what is the future of JJar?
> >
> > Tomek Pik
> > pikus@ais.pl
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by Henri Yandell <ba...@generationjava.com>.
I've been playing with it to use for work too. Trying to figure out what
advantages JJAR has over just using cvs and ant-cvs tasks.
On Tue, 19 Mar 2002, Tomasz Pik wrote:
> Jason van Zyl wrote:
>
> What about Commons-Sandbox JJar Component?
> I use a little modified version of this tool and I think this is a very
> good solution for 'continous integration' and managing of differen
> versions of libraries at all.
>
> BTW what is the future of JJar?
>
> Tomek Pik
> pikus@ais.pl
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Tomasz Pik <pi...@ais.pl>.
Jason van Zyl wrote:
> We're trying to encourage the use of a central repository of JARs.
> Having the one repository makes things like automatically downloading
> JARs easier for those who are interested in only developing or fixing
> the single package they are interested in.
>
> I'm only pointing out that we work in a similiar fashion in that we like
> to have everything checked out, that's generally how I work at any rate.
>
> I think that having a central repository of JARs would make a
> generalized continuous integration mechanism a little easier. Where a
> project is working against a known set of binaries and you're building
> every 5 minutes to find errors that have been introduced into a build.
> With a central repository of JARs this would work for any project.
What about Commons-Sandbox JJar Component?
I use a little modified version of this tool and I think this is a very
good solution for 'continous integration' and managing of differen
versions of libraries at all.
BTW what is the future of JJar?
Tomek Pik
pikus@ais.pl
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by Jason van Zyl <jv...@zenplex.com>.
On Mon, 2002-03-18 at 23:41, Craig R. McClanahan wrote:
>
> 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.
Just as a point to mention, this is how most of the Turbine developers
work. We generally check everything out we just have the additional step
of placing each produced JAR in a shared directory before building.
This process is now used in Maven, what Turbine is now using for all its
builds and for producing the Turbine sites, and it uses this method but
it could easily be made to accommodate other modes of developing.
We're trying to encourage the use of a central repository of JARs.
Having the one repository makes things like automatically downloading
JARs easier for those who are interested in only developing or fixing
the single package they are interested in.
I'm only pointing out that we work in a similiar fashion in that we like
to have everything checked out, that's generally how I work at any rate.
I think that having a central repository of JARs would make a
generalized continuous integration mechanism a little easier. Where a
project is working against a known set of binaries and you're building
every 5 minutes to find errors that have been introduced into a build.
With a central repository of JARs this would work for any project.
I'm also adjusting Maven to use a "dist" directory because I release all
of Turbine family yesterday trying to use Maven and it was a bit
cumbersome so I'm going to adopt the "dist" directory to try and make
this easier.
> (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.
Right, I think we have just evolved in different ways but I think a
central store of JARs may be easier for people to work with and this
doesn't prevent someone from creating these JARs on their own machines.
We use this method in Turbine coupled with an automatic JAR downloading
mechanism to help people who are not interested in building all the
dependencies.
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 21 Mar 2002, Daniel Rall wrote:
> Date: Thu, 21 Mar 2002 09:16:43 -0800
> From: Daniel Rall <dl...@finemaltcoding.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: property naming (Re: cvs commit: jakarta-commons/digester
> build.properties.sample)
>
> "Craig R. McClanahan" <cr...@apache.org> writes:
>
> > I'm likewise ok with switching the build.xml and build.properties.sample
> > defaults in Commons to ${lib.repo} style, if that's what people want --
> > just don't mess up my ability to override the locations of each individual
> > JAR file :-).
>
> I wouldn't dream of it -- I often need to do the same.
>
Would making this switch (changing build.properties.sample, and the
defaults in build.xml to ${lib.repo} based) be sufficient to make it
Maven-friendly?
For concreteness, let's consider the BeanUtils build.properties.sample.
The current file has (stripping comments out):
commons-collections.home=../collections/dist
commons-collections.jar=${commons-collections.home}/commons-collections.jar
commons-logging.home=../logging/dist
commons-logging.jar=${commons-logging.home}/commons-logging.jar
junit.home=/usr/local/junit3.7
junit.jar=${junit.home}/junit.jar
So, the proposal would be to change this to the following:
commons-collections.jar=${lib.repo}/commons-collections.jar
commons-logging.jar=${lib.repo}/commons-logging.jar
junit.jar=${lib.repo}/junit.jar
right? You would rely on the user to define their own lib.repo property
someplace if they are using this approach.
As long as everyone follows the convention that every JAR file is
represented by a property of the same name, it would seem like we can have
our cake and eat it too.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Craig R. McClanahan" <cr...@apache.org> writes:
> I'm likewise ok with switching the build.xml and build.properties.sample
> defaults in Commons to ${lib.repo} style, if that's what people want --
> just don't mess up my ability to override the locations of each individual
> JAR file :-).
I wouldn't dream of it -- I often need to do the same.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 3/19/02 12:50 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:
> I'm likewise ok with switching the build.xml and build.properties.sample
> defaults in Commons to ${lib.repo} style, if that's what people want --
> just don't mess up my ability to override the locations of each individual
> JAR file :-).
>
> Craig
+1
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 19 Mar 2002, Daniel Rall wrote:
> Date: Tue, 19 Mar 2002 11:41:32 -0800
> From: Daniel Rall <dl...@finemaltcoding.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: property naming (Re: cvs commit: jakarta-commons/digester
> build.properties.sample)
>
> Daniel Rall <dl...@finemaltcoding.com> writes:
>
> > "Craig R. McClanahan" <cr...@apache.org> writes:
> >
> >> but consistency within a particular philosophy is even more
> >> important than choosing one or the other.
>
> I responded to the wrong fragment of your message -- I agree with
> what's above (but stand by what I said). Teach me to spout
> controversy while still bleary-eyed. :)
>
I'm likewise ok with switching the build.xml and build.properties.sample
defaults in Commons to ${lib.repo} style, if that's what people want --
just don't mess up my ability to override the locations of each individual
JAR file :-).
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
> "Craig R. McClanahan" <cr...@apache.org> writes:
>
>> but consistency within a particular philosophy is even more
>> important than choosing one or the other.
I responded to the wrong fragment of your message -- I agree with
what's above (but stand by what I said). Teach me to spout
controversy while still bleary-eyed. :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Craig R. McClanahan" <cr...@apache.org> writes:
> The lib.repo approach puts an equally huge burden for people who are
> actively developing one or more of the Commons components -- just because
> it makes *your* life easier doesn't help *me* :-). I'm still going to
> have to create the bazillion individual properties to override the global
> assumption that all the JARs are in one place.
Placing all the JARs in one place is a very reasonable assumption (one
I'm hoping more projects adopt). It allows packages to build straight
out of CVS when the requisite JARs are present, or when a JAR-fetching
system is used. No futzing around with .sample files required -- just
type `ant` and watch it build. I have a great appreciation for this
interface due to its simplicity -- I don't have to deal with the
underlying complexity until I need the flexibility it supplies.
Experience has shown me that the Struts style build system does not
offer this benefit.
> In that respect, the two approaches are equivalent in the sense that they
> work well for some and not well for others.
I see what you're saying, and agree that for some components that this
is case. However, for the Digester's build.properties.sample (the
commit that started this thread), root is roughly equivalent to
lib.repo. Let's take another look at the diff:
> 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
Sure, setting root=${lib.repo} would have the desired effect.
However, renaming root to lib.repo would bring the two build schemes
closer together. Note that comparing this file with the top level
build.properties.sample shows that the semantics of root are different
for Digester than for top level.
Generally, I say to each his own. However, I have to deal with these
Struts style build systems on a daily basis and find them deficient.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 19 Mar 2002, Daniel Rall wrote:
> Date: Tue, 19 Mar 2002 09:23:53 -0800
> From: Daniel Rall <dl...@finemaltcoding.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: property naming (Re: cvs commit: jakarta-commons/digester
> build.properties.sample)
>
> "Craig R. McClanahan" <cr...@apache.org> writes:
>
> > both are equally valid, but consistency within a particular
> > philosophy is even more important than choosing one or the other.
>
> I don't agree. As I mentioned in my message in response to Jeff, and
> as you say above, build files following the Struts style make the
> (huge) assumption that the builder has setup their source trees in a
> single way. Though they are sometimes written to allow for alternate
> configurations, the unnecessary complexity introduced by the extra
> parameterization required to allow flexiblity for those who have not
> setup their source tree in a manner matching that of the build file
> author is not a good trade-off. Better to follow the proven precedent
> set by Unix years and years ago (I'm sure you remember, Craig *impish
> wink*) which has proven to work well.
>
The lib.repo approach puts an equally huge burden for people who are
actively developing one or more of the Commons components -- just because
it makes *your* life easier doesn't help *me* :-). I'm still going to
have to create the bazillion individual properties to override the global
assumption that all the JARs are in one place.
In that respect, the two approaches are equivalent in the sense that they
work well for some and not well for others.
> - Dan
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Craig R. McClanahan" <cr...@apache.org> writes:
> both are equally valid, but consistency within a particular
> philosophy is even more important than choosing one or the other.
I don't agree. As I mentioned in my message in response to Jeff, and
as you say above, build files following the Struts style make the
(huge) assumption that the builder has setup their source trees in a
single way. Though they are sometimes written to allow for alternate
configurations, the unnecessary complexity introduced by the extra
parameterization required to allow flexiblity for those who have not
setup their source tree in a manner matching that of the build file
author is not a good trade-off. Better to follow the proven precedent
set by Unix years and years ago (I'm sure you remember, Craig *impish
wink*) which has proven to work well.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: property naming (Re: cvs commit: jakarta-commons/digester
build.properties.sample)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 19 Mar 2002, Jeff Turner wrote:
> Date: Tue, 19 Mar 2002 15:33:28 +1100
> From: Jeff Turner <je...@socialchange.net.au>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> 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
>
> > jefft@apache.org 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Posted by Jeff Turner <je...@socialchange.net.au>.
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.
--Jeff
> jefft@apache.org 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons/digester build.properties.sample
Posted by Daniel Rall <dl...@finemaltcoding.com>.
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.
jefft@apache.org 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>