On Sat, 2003-09-20 at 15:41, Colin Sampaleanu wrote:I don't think you have much of a problem with it becuase you're using it simply as a source of globabl overrides, and that's not a very common occurrence.
I wanted to get the rationale as to why build.properties from ${user.home} is more dominant than build.properties and project.properties from the project dir.
To provide a final place where all values can be overridden. The asumption being that not many values would actually ever reside in ~/build.properties. As Maven is project centric it is assumed that all values of importance are specified at the project level. Given N maven projects with their own project.properties how many values in your ~/build.properties conflict with values in any of the project that use Maven to build?
omewhat of an unfortunate mess...
Well, I have exactly two entries in my ~/build.properties, I have never had a problem and I don't recall many other complaints about the dominance of the properties file processing.
s there any chance I can convince you guys to reverse the order?
Not without some examples of what the problem is. What exactly are you
having problems with?
My whole point is that as far as I can tell, more than half of the projects using this mechanism with ant build files use it as a source of defaults, not as a source of overrides. Now, without some sort of real standard, the mechanism is effectively useless for both sides. If you know that 60% of the builds are going to treat it one way, and 40% the other, then you can't rely on it at all...
As for using ~/build.properties as a source of defaults, there's plenty of stuff it makes sense to put in there. I've personally got a number of entries. For example, things like a default db password for building projects for dev use, which then get overriden as needed when building for staging or production use, etc. Things like my username, for inserting into build records, etc. If I want to switch to maven, these values suddently become overrides, and I have to take them out, and customize every project instead, or introduce another file with defaults.
As to why a '~/build.properties is defaults' approach makes more sense than a '~/build.properties is overrides' approach, here's a list:
- in an informal look at some dozens of open source projects that I had sitting on my filesystem, more than half used the defaults approach vs the other way arounnd (if they looked at ~/build.properties at all)
- multilevel ant projects have very often used the mechanism of a build.properties in the root folder, with build.properties in the subproject roots being dominant. If you consider that ~/build.properties is another level (or more) up from the main project root, it should have the least dominance.
- maven already allows extending and overriding a root project.xml with a subproject's project.xml. Now maven doesn't currently allow extending build.properties and project.properties from a root project, but when it does, I presume it makes sense to work the same way as for the project.xml, the lower level project is dominant. Same argument applies here as for ant then for ~/build.properties; it is 'farther away' from the subproject you are in, so should be less dominant.
So my suggestion is to make ~/build.properties the _least_ dominant, that is it would become a source of defaults, and add another file like ~/buildoverrides.properties (or whatever) which would provide overrides. Some people would be affected, but I doubt very many; as per your email, there is not much need of a global overrides mechanism, and because it overrides everything, you're not likely to put much in there. Also, this would be more in line with the way the majority of ant projects with care about ~/build.properties treat it, so less ant projects would be affected, and could make an easier transition to maven.
Regards, Colin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
