on 3/31/02 12:28 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> This is really irrelevant, because you have a set of defaults for configure,
> and then you generate make files - if we had a system to generate platform
> specific build.xml files, then I agree with you.
<http://jakarta.apache.org/turbine/maven/>
> But in this case, we have one build.xml, and that is our makefile, so to
> speak. There are properties that can be *overridden* via a
> build.properties. But having the defaults external as well is a bit
> superfluous. It sort of like having the velocity configuration defaults
> outside of the vel jar and us forcing people to put that file in the
> classpath too...
It isn't superfluous. You forgot my main point which is that I don't expect
*USERS* to look at a build.xml and know how to read it.
> How about an ant target that dumps out the default properties file? Then
> both problems are solved... One file for maintainability, and then for
> people who want to override the defaults, it spits out a default.props for
> them to start with.
Hmmm...that might work...I could go for that...it solves the problem of not
making users look inside of a build.xml file.
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
