(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]

Reply via email to