---- you <[EMAIL PROTECTED]> wrote ----
> Now what happens when I'm building multiple versions or multiple
> copies of the same version of a project on one box?
At some point, the user takes responsibility and supplies their own
properties to override the defaults... 8-)
Really - as long as the build script standard has clearly defined Ant
property names that control various fundamental things about the build
process (like the root of all compile/jar/doc/whatever output, etc.), then
each project might simply define their *own* defaults, but allow any users
to override these to point to the user's favorite areas. For example, on
Xalan, several developers have explicitly requested that the build.dir be
inside the project area - our default is ./build, which becomes
xml-xalan/java/build. I like Sam's Gump theory, where the project should
be allowed to define it's own defaults, but should have clearly specified
ways to override them if the user desires. Also many developers with
Windoze backgrounds don't use temp.dir in the same ways as or as frequently
as unix-y background developers.
I think one thing we do need to be clear on is the hierarchy of standard
property names. For example, all normal build output should be rooted
underneath build.dir. (i.e we define that any other properties like
build.docs.dir or check.dir or whatever all use build.dir as the base).
That way users know they can override just build.dir to move all output
somewhere else.
Am I making any sense?
- Shane
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
