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.
From my experience, it is indeed a problem when you need to make a system specific override for a set of related projects, but not for all the project I have in my system. A concrete example:
I have a bunch of projects in an eclipse workspace, about 5k files in total. I run maven tasks to generate javadocs, make wars and so on, the number of files in the workspace goes through the roof in an instant. This slows things down, especially searching.
My solution to this was adding the following to my ~/build.properties
maven.build.dir=/home/rafal/sandbox/maven-targets/${pom.artifactId}
this way maven generated stuff does not pollute my eclipse workspace.
Unfortunately this setting makes many project other break including Maven itself.
Obviously, I could add the above setting to the build.proprties of each of the projects in the workspace, but this just doesn't feel right to me. What if I decide to move the targets directory? Go through them again and update the path? Naaah...
I wish that we could introduce an intermediate step between ~/build.properties and ${basedir}/build.properties in an organized manner.
One solution would be traversing the directory tree upwards from
${basedir} to ${user.home} and combining the build.properties files.
(a weak point - what if user builds a project outside his/her $HOME?)
I second Colin's oppinion that ${basedir}/build.properties should be
dominant as they are the most specific, and each directory's
build.properties should be dominant over it's parent, ending with
~/build.properties that are most general and thus the weakest.Another solution that might fix things for many projects would be
inheriting build.properties from the parent project (in terms or <extends>, not directories). It won't fix my particular problem though as the projects in my workspace don't have a single parent project.
If the two above approaches are combined, a question remains if the
build.properties from the parent project (by extends) should be dominant over those forom the parend directory (by file system), or the other way
around.
I think that properties combining is one of the weakest points of Maven ATM. Especially MAVEN-37 (the longest standing bug in Maven, over a one year old). I'm sure that this will be sorted out sooner or later, and I
don't personally care if it's pre or post 1.0 as I try to keep up with
HEAD, but I'm sure that this will confuse the hell out of people flowing
into maven after 1.0 is announced. If I were you, Brave Developers, I would make fixing and documenting it a release blocker, for your own
sanity's sake.
R.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
