ant clean, should take care of that problem.
I consider a clean build a perquisite to tracking in bug from qa.
-----Original Message-----
From: Daniel Rall [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 26, 2001 10:02 AM
To: [EMAIL PROTECTED]
Subject: Re: Build.xml standardization
[EMAIL PROTECTED] writes:
> ---- 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-)
Very true. However, where do we draw the line? I should definitely
be able to build multiple versions of the same project on one box
without having to modify the build properties.
Use case:
I'm making extensive changes to version X of the SourceCast project in
my working copy. QA finds a P1 bug and I must drop everything and
work on fixing that. To successfully reproduce the bug, I need the
same version of SourceCast that QA is using, so I must check out
another working copy of version X from CVS. These two working copies
of the same version must not interfere w/ one another.
> 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.
Great, this is exactly what I'm talking about. :)
Keeping the temporary and build directories inside the project
directory satisfies the use case noted above.
> 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.
Yup, this works great. I use a project/build.properties and
~/build.properties for user overrides, and a
project/default.properties for all default properties for a project.
> 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.
Does build.dir referring to the final output of the build, and tmp.dir
to any intermediate output (i.e. .class files)?
> Am I making any sense?
Definitely.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
