You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2011/05/24 07:30:16 UTC
Moving forward with mixins
Hi,
I'm working with some projects at the moment that have a high amount of repetition in the build section (and in some cases dependencies), but no common parent due to different organisational hierarchies. Currently it's being solved by using archetypes to create projects consistently, but it isn't very satisfying if someone wants to change the archetype later on. I've minimised that by limiting what needs to change between projects based on the archetype, but it is exactly the situation that calls for mixins.
At the same time, this issue was filed today: http://jira.codehaus.org/browse/MNG-5102, and I was surprised not to find a dupe given how often it has come up here.
Previous discussions I found:
http://s.apache.org/maven-mixin-1
http://s.apache.org/maven-mixin-2
http://s.apache.org/maven-mixin-3
http://s.apache.org/maven-mixin-4
I don't see any concrete proposals, other than the notes from Jason Dillon. So, I thought I'd start collecting them here.
I actually prefer the name "template", so I'll use that here, but happy to take other's opinions on that.
--
Pre-requisites: the ability to make modifications to the POM, published to the repository, without impacting older clients. This needs an issue of it's own, but I don't think it's challenging if we continue to spit out v4.0.0 to the repository.
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), so that normal validation can be applied
- any POM element is valid, other than <parent>, <groupId>, <artifactId>, <version>, <templates>, <modules>
- templates need to be sourced from the repository using the normal mechanism (similarly to the parent POM)
- templates should have an extension "xml" in the repository. It is attached to the corresponding POM project with packaging "pom-template". Multiple templates can be attached using classifiers. The POM of the template must be separate to the template itself, as some elements would otherwise overlap (e.g. <name> of the template vs the templated name, or distributionManagement)
- we rely on the later interpolation step to resolve variables - there should be no filtering or macro capability on the template
- there should be no additional merge semantics - I think they can be handled very similarly to external profiles in terms of building
- there should be no conditionals within or around the template (that's the purpose of profiles)
I think that makes the sequence of project building:
- parents & templates are resolved
- templates are injected, sequentially as declared in the POM. Note that this happens before inheritance, so templates in parents are already applied.
- profiles are selected and injected
- project inheritance is applied
- interpolation is applied
Templates would be referenced as follows:
<project>
<parent>
...
</parent>
<templates>
<template>
<groupId>org.apache.maven.templates</groupId>
<artifactId>maven-release-profile-template</artifactId>
<version>1.0</version>
<classifier>sources-and-javadocs</classifier> (optional element)
</template>
<template>
<groupId>org.apache.maven.templates</groupId>
<artifactId>maven-team-list</artifactId>
<version>1.0</version>
</template>
</templates>
...
</project>
Some alternatives for discussion:
- we could allow profiles to be externalised, and use that instead of a new element. Simplifies building, but I think is less descriptive of intent
- template as a bare POM - instead of attached artifacts, <templateSpecs> could be inlined in the POM, deployed as a single POM and then imported into another project. This seems unnecessarily complicated, though.
- there are other alternatives on how it is packaged in the repository - e.g. a ".pomtmpl" extension or similar. If it is XML, I prefer that extension so it is more readily recognised, and I believe the group/artifact IDs will already describe their intent
Any thoughts?
Cheers,
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
Posted by John Casey <jd...@commonjava.org>.
Brett / Mark,
This all sounds great! I'm already dreaming of ways I could use this
functionality right now in my own builds...
Personally, I'm much more in favor of having separate template files in
the repository, since it helps keep the POMs associated with them lean,
and since it'll make the job of using these templates from other tooling
simpler.
Brett, I'm really starting to get interested in this post-4.0.0
formatting. I'm starting to remember a conversation I had last year this
time, about creating a new slave-pom specification for child modules
that will never be built outside the presence of the parent (where the
relativePath would always be valid, in 4.0.0 terms). That's getting a
little farther afield from the current conversation, but I wanted to
plant the seed... :-)
On 5/24/11 7:48 AM, Brett Porter wrote:
>
> On 24/05/2011, at 7:09 PM, Mark Derricutt wrote:
>
>> Great to see this being discussed.
>>
>>
>> Initial thoughts that come to mind reading that you've got here ( which for
>> the most part all looks good ).
>
> Cool!
>
>>
>> You mentioned the possibility of having the templates inline, rather than
>> <templateSpecs> I was wondering if using<templateManagement> to be
>> consistent with<dependencyManagement> and<pluginManagement>. If you have
>> multiple inline templates, how would you identify them?<id>'s like
>> plugins?
>>
>> <templateManagement>
>> <template>
>> <id>web</id>
>> <build>
>> <plugins>
>> ...
>> </plugins>
>> </build>
>> </template>
>> </templateManagement>
>>
>> Feels really ik and complicated as you say.
>
> Yep :) I don't see any hassle in pulling these files from the repository - the only inline usecase is actually to do something once and use it several times in a POM, but ruling out parameterisation doesn't make that useful.
>
>> If the template was external,
>> how does the template file get attached/referenced? At work, we currently
>> use the build-helper-plugin from codehaus to attach additional files to our
>> build to push to the repository, maybe pulling that plugin, or a variation
>> of it in as something to attach template files ( or any ) to the build, and
>> still have the<template/> section you mention to use them.
>
> Yep, a packaging plugin that is very simple and uses the same calls as the build-helper, resulting in something like:
>
> pom.xml
>
> <project xmlns...>
> <groupId>org.apache.maven.templates</groupId>
> <artifactId>maven-release-profile-template</artifactId>
> <version>1.0-SNAPSHOT</version>
> <packaging>pom-template</packaging>
> </project>
>
> pom-template.xml (default)
>
> <project xmlns...>
> (no coordinates)
> <build>
> ...
> </project>
>
> Then, if you have multiple, pom.xml is:
>
> <project xmlns...>
> <groupId>org.apache.maven.templates</groupId>
> <artifactId>maven-release-profile-template</artifactId>
> <version>1.0-SNAPSHOT</version>
> <packaging>pom-template</packaging>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-pom-template-plugin</artifactId>
> <version>1.0</version>
> <configuration>
> <templates>
> <template>
> <file>pom-template-source-and-javadocs.xml</file>
> <classifier>source-and-javadocs</classifier>
> </template>
> <template>
> <file>pom-template-source-only.xml</file>
> <classifier>source-only</classifier>
> </template>
> </templates>
> </configuration>
> </plugin>
> </plugins>
> </build>
> </project>
>
>
>>
>> The other idea I had a long time ago when thinking about this briefly, is
>> there any way of using XInclude [1] with a custom URI resolver for
>> repositories to just pull in POM parts ( not as type safe tho ).
>>
>> <project xmlns:xi="http://www.w3.org/2001/XInclude">
>> <groupId>com.mytest</groupId>
>> <artifactId>mytest</artifactId>
>> <version>1.0-SNAPSHOT</version>
>>
>> <xi:include href="com.mytest:mymixin:1.0:xml" xpointer="mixindeps"/>
>>
>> </project>
>>
>>
>> ( here - mymixin.xml could be a standard pom, with<dependencies
>> id="mixingdeps">
>>
>>
>> [1] http://www.w3.org/TR/xinclude/
>
> Someone else raised this in the threads I listed, but I think we want to retain the ability to describe the POM in things that aren't XML.
>
> - 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
Posted by Brett Porter <br...@apache.org>.
On 24/05/2011, at 7:09 PM, Mark Derricutt wrote:
> Great to see this being discussed.
>
>
> Initial thoughts that come to mind reading that you've got here ( which for
> the most part all looks good ).
Cool!
>
> You mentioned the possibility of having the templates inline, rather than
> <templateSpecs> I was wondering if using <templateManagement> to be
> consistent with <dependencyManagement> and <pluginManagement>. If you have
> multiple inline templates, how would you identify them? <id>'s like
> plugins?
>
> <templateManagement>
> <template>
> <id>web</id>
> <build>
> <plugins>
> ...
> </plugins>
> </build>
> </template>
> </templateManagement>
>
> Feels really ik and complicated as you say.
Yep :) I don't see any hassle in pulling these files from the repository - the only inline usecase is actually to do something once and use it several times in a POM, but ruling out parameterisation doesn't make that useful.
> If the template was external,
> how does the template file get attached/referenced? At work, we currently
> use the build-helper-plugin from codehaus to attach additional files to our
> build to push to the repository, maybe pulling that plugin, or a variation
> of it in as something to attach template files ( or any ) to the build, and
> still have the <template/> section you mention to use them.
Yep, a packaging plugin that is very simple and uses the same calls as the build-helper, resulting in something like:
pom.xml
<project xmlns...>
<groupId>org.apache.maven.templates</groupId>
<artifactId>maven-release-profile-template</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom-template</packaging>
</project>
pom-template.xml (default)
<project xmlns...>
(no coordinates)
<build>
...
</project>
Then, if you have multiple, pom.xml is:
<project xmlns...>
<groupId>org.apache.maven.templates</groupId>
<artifactId>maven-release-profile-template</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom-template</packaging>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pom-template-plugin</artifactId>
<version>1.0</version>
<configuration>
<templates>
<template>
<file>pom-template-source-and-javadocs.xml</file>
<classifier>source-and-javadocs</classifier>
</template>
<template>
<file>pom-template-source-only.xml</file>
<classifier>source-only</classifier>
</template>
</templates>
</configuration>
</plugin>
</plugins>
</build>
</project>
>
> The other idea I had a long time ago when thinking about this briefly, is
> there any way of using XInclude [1] with a custom URI resolver for
> repositories to just pull in POM parts ( not as type safe tho ).
>
> <project xmlns:xi="http://www.w3.org/2001/XInclude">
> <groupId>com.mytest</groupId>
> <artifactId>mytest</artifactId>
> <version>1.0-SNAPSHOT</version>
>
> <xi:include href="com.mytest:mymixin:1.0:xml" xpointer="mixindeps"/>
>
> </project>
>
>
> ( here - mymixin.xml could be a standard pom, with <dependencies
> id="mixingdeps">
>
>
> [1] http://www.w3.org/TR/xinclude/
Someone else raised this in the threads I listed, but I think we want to retain the ability to describe the POM in things that aren't XML.
- 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
Posted by Brett Porter <br...@apache.org>.
Hi Maurizio,
Re-reading this, I saw before we had a lot of agreement, but re-reading I see you also had a question...
On 25/05/2011, at 1:44 AM, Maurizio Pillitu wrote:
>> However, I'm sure you're already noticing some limitations:
>> - you can't get in before interpolation, so properties used anywhere other
>> than plugin configuration will not be set
>>
>
> Yes, this is probably the biggest issue ATM with this approach, but I
> thought there would be good opportunities to fix it. I don't know how Maven
> interpolation works, so I don't have an idea how to solve this; could you
> provide me any pointers on code so that I can have a look (and learn some
> more) ?
There was talk about a spec for this in the past, but I can't find an up to date document. maven-core/project-builder.txt is empty.
My point was that there is no hook in Maven to get in before interpolation - the extension mechanism only deals with the constructed projects. That's why I was suggesting we would need to make modifications to the model builder.
The code to look at would be the maven-model-builder and some of the DefaultProjectBuilder in maven-core.
HTH,
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
Posted by Maurizio Pillitu <ma...@pillitu.name>.
Hi Brett,
thanks for your positive feedback! My answers interleaved....
> This is a good proof-of-concept, perhaps worth trying on some projects to
> see how it goes without needing to use a new Maven version.
>
I've tried already with the wicket-quickstart (one of the easiest archetypes
to test) and I was planning to test others; any specific project/build that
you'd be interested to try out?
> I was surprised that you could get that far with the existing extension
> mechanism - it seems the model mergers are helping get this mostly right :)
>
> Me too! :) It was also the first time I was 'hacking' around Maven Core and
I wasn't expecting such a result; a good chance to kudo Maven devs for
providing such a simple way to inject logic within Maven. FTR, the
ThycoMavenLifecycleParticipant[1] helped a lot ;-)
> However, I'm sure you're already noticing some limitations:
> - you can't get in before interpolation, so properties used anywhere other
> than plugin configuration will not be set
>
Yes, this is probably the biggest issue ATM with this approach, but I
thought there would be good opportunities to fix it. I don't know how Maven
interpolation works, so I don't have an idea how to solve this; could you
provide me any pointers on code so that I can have a look (and learn some
more) ?
> - the POM has to be completely valid, which risks dropping in unwanted
> elements to the target (like name of tile, distribution management, etc.) if
> the consumer forgets
>
True, I did not think of it; the problem here is that the POM file which
represents the tile should not allow any lifecycle executions (on the tile
itself) rather than install & deploy (and should not need any additional POM
elements than artifactId,groupId,version and packaging).
A "template" (or "tile") packaging would solve the issue tough, since we can
introduce a custom lifecycle and inhibit all unwanted lifecycle executions
> - you can't utilise dependency ordering to pick up templates from the
> reactor if you want to build them in your multi-module build and then use
> them again
>
True. I think that tiles are not the best way to include dependencies
indeed, but you can simply use transitive deps to get the very same result;
in my POM I can define a dep to a another POM file which just contains
dependencies. I would not handle dependencies in any other way than
transitive dependencies, whatever the Mixin approach would be, but that's
just a personal thought.
> - without POM changes, it can look a bit messier
>
> I don't understand this; what do you mean with "POM changes"? you're
referring to SCM changes?
> I also noticed you're impacting the raw model - was that necessary to work,
> or just part of the experimenting?
>
> It's part of the experiment, but I'm not sure if it's still needed; will do
some further investigation.
> What are your thoughts on my other comments about a general approach, if it
> can be built into the model building?
>
Well, looking at the first email of this thread, I see a lot of common
points between your approach and mine:
- templates should look like a normal POM....
Agree. ATM a tile is a POM
- any POM element is valid, other than ...., <templates>
Completely agree, the <templates> element looks awesome and cool; in my
solution I just wanted to 'postpone' this issue and use the <properties> tag
with a simple naming convention, but your <templates> solution is where I
was aiming at.
- templates need to be sourced from the repository using the normal
mechanism....
Agree. I use Aether to resolve deps and it works like a charm.
- templates should have an extension "xml" in the repository ...
Agree. I think that having a different packaging for templates/tiles/mixin
(whatever the name will be :-) would make it cleaner and clearer for users;
however, if we *really* can make it working by just using a POM packaging,
this issue is not really a priority and could be considered a nice to have,
agree?
- we rely on the later interpolation step to resolve variables....
Agree, and that's where Tiles fails ATM (as discussed above)
- there should be no additional merge semantics....
Agree and done, ModelMerger rocks :-)
- ... the sequence of project building...
Agree, but I need to know more about Maven internals to have a better
opinion on that.
Sorry for the long email!
--
Maurizio Pillitu
http://maurizio.pillitu.name
maurizio@pillitu.name
[1] -
http://www.jarvana.com/jarvana/view/org/sonatype/tycho/tycho-osgi-components/0.7.0/tycho-osgi-components-0.7.0-sources.jar!/org/codehaus/tycho/maven/TychoMavenLifecycleParticipant.java
Re: Moving forward with mixins
Posted by Brett Porter <br...@apache.org>.
On 24/05/2011, at 7:22 PM, Maurizio Pillitu wrote:
> Hi Mark,
>
> really interesting discussion indeed.
>
> I like very much your idea of including mixins within POM files; this
> weekend I did some code (which is actually very very similar to your
> description) and I ended up with something working.
>
> I've contributed my code to http://jira.codehaus.org/browse/MNG-5102
>
> Hope this helps!
This is a good proof-of-concept, perhaps worth trying on some projects to see how it goes without needing to use a new Maven version. I was surprised that you could get that far with the existing extension mechanism - it seems the model mergers are helping get this mostly right :)
However, I'm sure you're already noticing some limitations:
- you can't get in before interpolation, so properties used anywhere other than plugin configuration will not be set
- the POM has to be completely valid, which risks dropping in unwanted elements to the target (like name of tile, distribution management, etc.) if the consumer forgets
- you can't utilise dependency ordering to pick up templates from the reactor if you want to build them in your multi-module build and then use them again
- without POM changes, it can look a bit messier
I also noticed you're impacting the raw model - was that necessary to work, or just part of the experimenting?
What are your thoughts on my other comments about a general approach, if it can be built into the model building?
- 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
Posted by Maurizio Pillitu <ma...@pillitu.name>.
Hi Mark,
really interesting discussion indeed.
I like very much your idea of including mixins within POM files; this
weekend I did some code (which is actually very very similar to your
description) and I ended up with something working.
I've contributed my code to http://jira.codehaus.org/browse/MNG-5102
Hope this helps!
Maurizio
On Tue, May 24, 2011 at 11:09 AM, Mark Derricutt <ma...@talios.com> wrote:
> Great to see this being discussed.
>
>
> Initial thoughts that come to mind reading that you've got here ( which for
> the most part all looks good ).
>
> You mentioned the possibility of having the templates inline, rather than
> <templateSpecs> I was wondering if using <templateManagement> to be
> consistent with <dependencyManagement> and <pluginManagement>. If you
> have
> multiple inline templates, how would you identify them? <id>'s like
> plugins?
>
> <templateManagement>
> <template>
> <id>web</id>
> <build>
> <plugins>
> ...
> </plugins>
> </build>
> </template>
> </templateManagement>
>
> Feels really ik and complicated as you say. If the template was external,
> how does the template file get attached/referenced? At work, we currently
> use the build-helper-plugin from codehaus to attach additional files to our
> build to push to the repository, maybe pulling that plugin, or a variation
> of it in as something to attach template files ( or any ) to the build, and
> still have the <template/> section you mention to use them.
>
> The other idea I had a long time ago when thinking about this briefly, is
> there any way of using XInclude [1] with a custom URI resolver for
> repositories to just pull in POM parts ( not as type safe tho ).
>
> <project xmlns:xi="http://www.w3.org/2001/XInclude">
> <groupId>com.mytest</groupId>
> <artifactId>mytest</artifactId>
> <version>1.0-SNAPSHOT</version>
>
> <xi:include href="com.mytest:mymixin:1.0:xml" xpointer="mixindeps"/>
>
> </project>
>
>
> ( here - mymixin.xml could be a standard pom, with <dependencies
> id="mixingdeps">
>
>
> [1] http://www.w3.org/TR/xinclude/
>
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On Tue, May 24, 2011 at 5:30 PM, Brett Porter <br...@apache.org> wrote:
>
> > <templateSpecs>
>
--
Maurizio Pillitu
http://maurizio.pillitu.name
maurizio@pillitu.name
Re: Moving forward with mixins
Posted by Mark Derricutt <ma...@talios.com>.
Great to see this being discussed.
Initial thoughts that come to mind reading that you've got here ( which for
the most part all looks good ).
You mentioned the possibility of having the templates inline, rather than
<templateSpecs> I was wondering if using <templateManagement> to be
consistent with <dependencyManagement> and <pluginManagement>. If you have
multiple inline templates, how would you identify them? <id>'s like
plugins?
<templateManagement>
<template>
<id>web</id>
<build>
<plugins>
...
</plugins>
</build>
</template>
</templateManagement>
Feels really ik and complicated as you say. If the template was external,
how does the template file get attached/referenced? At work, we currently
use the build-helper-plugin from codehaus to attach additional files to our
build to push to the repository, maybe pulling that plugin, or a variation
of it in as something to attach template files ( or any ) to the build, and
still have the <template/> section you mention to use them.
The other idea I had a long time ago when thinking about this briefly, is
there any way of using XInclude [1] with a custom URI resolver for
repositories to just pull in POM parts ( not as type safe tho ).
<project xmlns:xi="http://www.w3.org/2001/XInclude">
<groupId>com.mytest</groupId>
<artifactId>mytest</artifactId>
<version>1.0-SNAPSHOT</version>
<xi:include href="com.mytest:mymixin:1.0:xml" xpointer="mixindeps"/>
</project>
( here - mymixin.xml could be a standard pom, with <dependencies
id="mixingdeps">
[1] http://www.w3.org/TR/xinclude/
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Tue, May 24, 2011 at 5:30 PM, Brett Porter <br...@apache.org> wrote:
> <templateSpecs>
Re: Moving forward with mixins
Posted by Arnaud Héritier <ah...@gmail.com>.
The main issue with mixins is to define in which part of
the resolution mechanism we need to apply it and all the rules to override
or add entries in the POM
We need to provide flexibility but in an understandable way.
nowadays it is already difficult sometime to know why when the POM is
resolved we have this or this setting because of the inheritence, profiles
...
Adding mixins will add complexity and we need to take care of it
On Tue, May 24, 2011 at 4:34 PM, Jesse Glick <je...@oracle.com> 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?
>
> <project>
> <parents>
> <parent> <!-- licenses, etc. -->
> <groupId>com.yoyodyne.poms</>
> <artifactId>general</>
> <version>5</>
> </>
> <parent>
> <groupId>com.yoyodyne.poms</>
> <artifactId>java</>
> <version>2</>
> </>
> <parent>
> <groupId>com.yoyodyne.poms</>
> <artifactId>jpa</>
> <version>1</>
> </>
> </>
> <groupId>com.yoyodyne.labs</>
> <artifactId>newstuff</>
> <version>1.0</>
> <!-- ... -->
> </>
>
> $repo/com/yoyodyne/poms/general/5/general-5.pom,
> $repo/com/yoyodyne/poms/java/2/java-2.pom, and
> $repo/com/yoyodyne/poms/jpa/1/jpa-1.pom (as well as anything they in turn
> declared via <parent>) would be consulted for defaults in all the usual
> places, such as pluginManagement.
>
> 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.)
>
> The main drawback I can see is that you would not be able to inherit any
> elements the presence of which would cause an empty pom-packaging project
> (the mixin parent) to not be buildable. I think this is what you were
> getting at when you said "[t]he POM of the template must be separate to the
> template itself". For example, a parent could not actually declare a plugin
> if that plugin gave an error when relevant source files were missing (e.g.
> exec-maven-plugin). On the other hand, the parent could do all the
> interesting work in pluginManagement, and the child would just need to turn
> that plugin on (specifying only groupId and artifactId). Also, some plugins
> are harmless no-ops when present in a parent POM; and this is not an issue
> for plugins mentioned in the lifecycle, which would be enabled anyway.
>
> You could escape this drawback, where it mattered, by making the actual
> mixin be a secondary pom-type artifact (attached with install:install-file,
> say). This *.pom would not be "executed" when installing the mixin, just
> copied. You would need to permit <classifier> as a child of <parent> so this
> artifact could be selected.
>
> 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>.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Moving forward with mixins
Posted by 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
Posted by 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
Posted by 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
Re: Moving forward with mixins
Posted by 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
Posted by Jesse Glick <je...@oracle.com>.
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?
<project>
<parents>
<parent> <!-- licenses, etc. -->
<groupId>com.yoyodyne.poms</>
<artifactId>general</>
<version>5</>
</>
<parent>
<groupId>com.yoyodyne.poms</>
<artifactId>java</>
<version>2</>
</>
<parent>
<groupId>com.yoyodyne.poms</>
<artifactId>jpa</>
<version>1</>
</>
</>
<groupId>com.yoyodyne.labs</>
<artifactId>newstuff</>
<version>1.0</>
<!-- ... -->
</>
$repo/com/yoyodyne/poms/general/5/general-5.pom, $repo/com/yoyodyne/poms/java/2/java-2.pom, and $repo/com/yoyodyne/poms/jpa/1/jpa-1.pom (as well as anything they in turn
declared via <parent>) would be consulted for defaults in all the usual places, such as pluginManagement.
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.)
The main drawback I can see is that you would not be able to inherit any elements the presence of which would cause an empty pom-packaging project (the mixin parent) to
not be buildable. I think this is what you were getting at when you said "[t]he POM of the template must be separate to the template itself". For example, a parent could
not actually declare a plugin if that plugin gave an error when relevant source files were missing (e.g. exec-maven-plugin). On the other hand, the parent could do all
the interesting work in pluginManagement, and the child would just need to turn that plugin on (specifying only groupId and artifactId). Also, some plugins are harmless
no-ops when present in a parent POM; and this is not an issue for plugins mentioned in the lifecycle, which would be enabled anyway.
You could escape this drawback, where it mattered, by making the actual mixin be a secondary pom-type artifact (attached with install:install-file, say). This *.pom would
not be "executed" when installing the mixin, just copied. You would need to permit <classifier> as a child of <parent> so this artifact could be selected.
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>.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org