I wondered about the import restriction for a long time already. Imo this _exactly_ feels natural. Much more than having multiple parents.
Also the pom for the main artifacts might stay pretty much 4.0, but our MavenProject Parser would need more fidling. Of course we could define a new packaging 'ppom' (partial pom) or kind of for the parts which can get imported. A minor problem could be in which sorting order to add <plugins> from any imported ppom to the project. And how merging/overriding would look like if an imported ppom defines the same plugin GAV as the pom. ppoms can of course import other ppoms and build a hierarchy that way. LieGrue, strub --- On Fri, 6/17/11, Brett Porter <[email protected]> wrote: > From: Brett Porter <[email protected]> > Subject: Re: Moving forward with mixins > To: "Maven Developers List" <[email protected]> > Date: Friday, June 17, 2011, 12:11 AM > (sorry for the delay, I've not > forgotten, just been busy) > > On 25/05/2011, at 12:34 AM, Jesse Glick 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? > > While I think it should be very close in behaviour, there's > a fairly significant semantic difference between the parent > and the mixin. The parent offers some grouping - a canonical > set of stuff several projects pick up, where a mixin is > something a project pulls in to add to itself. For example, > you said: > > > 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.) > > This makes the first parent special, which is potentially > confusing and its better to be explicit. > > > 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>. > > > I think that scope is a bit confusing, and not frequently > used. It's really time we stopped applying bandaids and made > it possible to change the POM... > > FWIW, I did start to port my previous work to get that > happening. The main thing I'm still working on is > identifying the touchpoints so that POMs in the repository > work across both Maven 2 & 3. If anyone wants to help > with that, let me know... > > - Brett > > -- > Brett Porter > [email protected] > http://brettporter.wordpress.com/ > http://au.linkedin.com/in/brettporter > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
