maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <colin...@exis.com>
Subject Re: Why is build.properties from ${user.home} the most dominant
Date Sun, 21 Sep 2003 15:03:04 GMT
Jason van Zyl wrote:

>On Sat, 2003-09-20 at 15:41, Colin Sampaleanu wrote:
>  
>
>>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?
>  
>
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.

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message