On Tue, Mar 19, 2002 at 09:14:53AM -0800, Daniel Rall wrote:
> Jeff Turner <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
