On 05/24/2011 01:30 AM, Brett Porter wrote:
Some notes on how I think it should work:
- templates should look like a normal POM (perhaps only differing in root
element, and less strict validation requirements) [...]
- any POM element is valid, other than
<parent>,<groupId>,<artifactId>,<version>,<templates>,<modules>
- templates need to be sourced from the repository [...]
- templates should have an extension "xml" in the repository. [...]
Maybe I am missing some unmentioned constraints, but the problem as I see it is just that the existing <parent> mechanism does not support multiple inheritance. The
sketch above sounds like something that is similar to regular inheritance, yet syntactically different, and requiring a new packaging etc. If the POM schema for the child
(~ importer) needs to be extended anyway, why not make it look and work as much as possible like the existing mechanism?
<project>
<parents>
<parent> <!-- licenses, etc. -->
<groupId>com.yoyodyne.poms</>
<artifactId>general</>
<version>5</>
</>
<parent>
<groupId>com.yoyodyne.poms</>
<artifactId>java</>
<version>2</>
</>
<parent>
<groupId>com.yoyodyne.poms</>
<artifactId>jpa</>
<version>1</>
</>
</>
<groupId>com.yoyodyne.labs</>
<artifactId>newstuff</>
<version>1.0</>
<!-- ... -->
</>
$repo/com/yoyodyne/poms/general/5/general-5.pom, $repo/com/yoyodyne/poms/java/2/java-2.pom, and $repo/com/yoyodyne/poms/jpa/1/jpa-1.pom (as well as anything they in turn
declared via <parent>) would be consulted for defaults in all the usual places, such as pluginManagement.
You would of course have to define some logic for picking which parent (or grandparent...) "wins" in case of a conflict on some item. I think the most natural choice is a
depth-first search up through the parent graph, in the declared order. (Note that this implies that groupId, artifactId, and version may be inherited as before, but only
from the first declared parent.)
The main drawback I can see is that you would not be able to inherit any elements the presence of which would cause an empty pom-packaging project (the mixin parent) to
not be buildable. I think this is what you were getting at when you said "[t]he POM of the template must be separate to the template itself". For example, a parent could
not actually declare a plugin if that plugin gave an error when relevant source files were missing (e.g. exec-maven-plugin). On the other hand, the parent could do all
the interesting work in pluginManagement, and the child would just need to turn that plugin on (specifying only groupId and artifactId). Also, some plugins are harmless
no-ops when present in a parent POM; and this is not an issue for plugins mentioned in the lifecycle, which would be enabled anyway.
You could escape this drawback, where it mattered, by making the actual mixin be a secondary pom-type artifact (attached with install:install-file, say). This *.pom would
not be "executed" when installing the mixin, just copied. You would need to permit <classifier> as a child of <parent> so this artifact could be selected.
Note: the functionality of scope=import in current versions of Maven, limited to supplying <dependencyManagement>, would be subsumed by a feature like this. If you really
wanted to avoid any XSD change to pom.xml you could just broaden the interpretation of scope=import (so it could inherit other configuration, and perhaps could be
permitted in regular <dependencies> outside of <dependencyManagement>), though the syntax would be less intuitive than <parents>.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
