On 6/16/11 8:11 PM, Brett Porter wrote:
(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...
While I agree that we should be engaging in design a little more and
avoiding bandaid fixes for things, I will say that the import scope
brings a lot of potential for standardizing dependency versions - both
privately within a large collection of projects, and publicly for users
of those projects.
It's not the most elegant solution, though...
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]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
