Hi Anders, On Thu, 2011-04-07 at 14:26 +0200, Anders Hammar wrote: > First of all, I think that you're addressing the (what I call) developer way > by adding properties for many tings. Even if this would work, it makes the > poms difficult to read and understand. What I'm trying to do is to make the *developers' POMs* as easy to read and understand as possible - a single property that defines the location of the scm, documentation, a.s.o. is all that would have to be defined. I don't care as much for the company and project parent POMs as most developers will never touch or even look at them, if things work out ok for them.
> I believe future tooling support > (like m2eclipse) will solve some of this, but I still regard this as the > developer's approach. Unfortunately I cannot wait for the tooling support to happen - and yes, I'm approaching this as a developer who wants to have maximal (configuration) re-use. I'm trying to swing with the "Convention over Configuration" approach, but there are some boundaries here that I just cannot ignore without loosing acceptance for Maven - one of them being that I cannot disrupt development for reorganizing the structure of the SCM: A lot of (somewhat brittle) scaffolding has been built around the SCM structure that I intend to get rid of, but I can only do it bottom-up, one project & one library at a time, while the whole rest of the system still behaves and builds as before. > For example, I would leave the "generic" scm section out of the corporate > pom. Or more correctly, the corporate pom will have a scm section specifying > (without the usa of properties) the path to the scm where the corporate pom > is located. Then for each product, the parent pom would override this by > declaring the correct scm path for it. ... and the correct site path, and the correct documentation URL, ... leading to larger POMs and configuration information spreading throughout all POMs? There must be a better way! > Have a look at how the corporate pom at Apache, Codehaus, etc is made up. > Best-practice that works. It will give you some hints of configuration that > you corp parent do lack. I did have a look at the ASF POM and I cut out a lot of the stuff that is in my top-level POM for brevity on the list. Cheers, Wolf >> Cut for brevity. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
