commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)
Date Tue, 19 Mar 2002 22:17:47 GMT
On Tue, Mar 19, 2002 at 09:14:53AM -0800, Daniel Rall wrote:
> Jeff Turner <jeff@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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message