Re: Moving forward with mixins

[Brett Porter <br...@apache.org>]

(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
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Moving forward with mixins

[Benson Margulies <bi...@gmail.com>]

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 <st...@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" <de...@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
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Moving forward with mixins

[John Casey <jd...@commonjava.org>]

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
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

-- 
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Moving forward with mixins

[Mark Struberg <st...@yahoo.de>]

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" <de...@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
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org