On 5/24/11 8:25 AM, Brian Fox wrote:
2011/5/24 Arnaud Héritier<[email protected]>:
Before talking about a specific change in the model like the addition of
mixins (which may be cool but not critical) did we :
- studied that we had everything necessary to manage new versions of POMs
with something a little bit dynamic inside the core and all that is
necessary on repositories side ?
- studied if we couldn't start by really simple issues that may already do a
very useful 3.1 version like the addition of global exclusions ?
I didn't read the proposal in detail yet, but my initial concern was
on pom compat as well.
I think doing some sort of on-the-fly translation into a 4.0.0 POM
purely to be deployed for backwards compat would be enough here...though
we may want to explore how we could make Maven smart enough to say, "I
can't read this POM, use a later version" or somesuch...
Arnaud
On Tue, May 24, 2011 at 7:30 AM, Brett Porter<[email protected]> wrote:
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
[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]
---------------------------------------------------------------------
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]
