A highly confusing situation in the current design results from the interaction of <parent/>, aggregation, and the site plugin.
Superficially, it seems very natural: the usual practice is for an aggregating project to be the parent of its modules. Even the terminology is painful: we don't really have a clear term for 'uses project X as parent'. 'Child' is ambiguous, as it could either mean 'is a module of' or 'uses as a parent'. The situation is OK so long as the aggregating project does absolutely nothing except the simplest aggregation. The problem is that there is a conflict between controlling behavior in the aggregating project and setting defaults for the modules. One way to characterize a lack here is this: I'd like to have a <pluginManagement/> that applies *only* to the children, not to the current project. So the current way out of this is to make a more complex structure where the aggregating project is not the parent of its modules. Immediately, problems ensue with the site plugin, as it defaults to constructing pathnames on the assumption that modules use their aggregating project as parent. It's possible to fix this with a lot of dorking around with pathnames in <url> elements. What I want is for the site pathname structure and scm url structure to be inheritable in the obvious way while at the same time being able to block dependency and plugin configuration inheritance. This could be addressed by more attributes like the 'combine' attributes that I just added to the pom doc where they were mysteriously absent since their creation. Or there could be options on the <parent/> element, though it seems painful to have to do this over and over in each child. I think I'm looking for <localConfiguation>. This element could contain <build> or even <pluginManagement> or <dependencyManagement>, and would be defined to effect *only the current project*, not any other project that happens to use it as a parent. On Fri, Jun 17, 2011 at 3:09 AM, Mark Struberg <strub...@yahoo.de> wrote: > 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 <br...@apache.org> wrote: > >> From: Brett Porter <br...@apache.org> >> Subject: Re: Moving forward with mixins >> To: "Maven Developers List" <dev@maven.apache.org> >> 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 >> br...@apache.org >> http://brettporter.wordpress.com/ >> http://au.linkedin.com/in/brettporter >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
