lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Goetz <>
Subject Re: Build file changes
Date Mon, 11 Mar 2002 22:07:28 GMT
> Hey all, after all of the discussion that went on, I just want to confirm
> that the build file changes that I made with regards to the properties
> settings are indeed cool with everyone and that no one was overly put out by
> those changes.
>     Any real/major complaints?

I think the idea is a good one, and I've adopted the
idea in other projects, but I've got a suggestion for making it
slightly better (which might quell some of the complaints.)  

I like the idea of separating environment-specific properties from
project-specific properties.  For example, the structure of the source
tree and distribution kit is part of the project, wheras the location
of the JavaCC install, or the favorite Java compiler, or the location
of the jakarta-site2 stuff is part of the environment.  

Properties describing the user's environment should go in the user's
~/  It would be nice if the structure of
reflected the fact that there are three categories of properties there:
 - properties that are part of the project structure, and expected to
   not change very often.
 - properties that will change often, like the version number 
 - properties that the user may want to override in his ~/,
   like build.compiler and the location of the JavaCC install.  

Simply dividing b.p into three sections, with appropriate comments,
would be helpful.

I'd further consider moving the properties in the first category,
those that structure the project and which are not really designed to
be changed without other major changes to the project, back into the
build.xml.  That way, b.p would have only highly dynamic or
environment-speicific properties, and b.xml would have only structural
properties.  Since the goal (I assume) was factoring out the dynamic
stuff so users don't have to edit b.xml to change the
version/environment, this seems to more explicitly follow that goal.  

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message