on 2/26/02 7:45 PM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote:
> Agreed. I would say that this is a good argument for getting rid of > build.properties.sample altogether. Its not really needed, and anyone > wanting to tweak anything would likely have the know-how to figure out which > property they wanted to override by just looking at the top of build.xml. > > I don't disapprove of the way you recommend. I think we can just chalk it > up to a matter of preference. > > There are many projects that follow the build.properties.sample pattern > (Slide, Cactus, Commons, Struts, at least on my local perhaps slightly > outdated codebases). Notice that you mention projects which have been influenced by Craig's build system "ideas". :-) > I actually prefer no build.properties.sample. > > My argument against default.properties is that lazy folks would just edit > properties there rather than figuring out that they could override them by > creating a new file. A developer is much less likely to touch build.xml, > and would quickly (with a little bit of Ant know-how) see the override files > available. If we can get more projects to use a standard of having people create their own 'build.properties' then that isn't an issue. IMHO, build.xml shouldn't contain any properties that should be overridden by the user. The (lazy) user shouldn't have to even look at the build.xml to figure out what they should do to customize things. Doing so requires a (not so lazy) knowledge of Ant and XML which they might not have. Having them create their own build.properties to override the default.properties allows them to only look at a simple (lazy) properties text file. The argument of needing both a build.xml and default.properties doesn't really fly with me. The user shouldn't even have to look at the build.xml *ever*. -jon -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
