The main issue with mixins is to define in which part of the resolution mechanism we need to apply it and all the rules to override or add entries in the POM We need to provide flexibility but in an understandable way. nowadays it is already difficult sometime to know why when the POM is resolved we have this or this setting because of the inheritence, profiles ... Adding mixins will add complexity and we need to take care of it
On Tue, May 24, 2011 at 4:34 PM, Jesse Glick <[email protected]> wrote: > 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] > >
