+1
Also, generated 4.0.0 POMs should only contain deps and things to
support deps, not build section etc.
In other words, it's not to be used as a parent...if you can't use the
newer POM syntax, don't use this artifact as a parent.
On 5/24/11 11:17 AM, Stephen Connolly wrote:
deploy new poms as poms with classifier
new maven tries to download pom with classifier... fails and falls
back to pom without
old maven only ever sees pom without classifier
2011/5/24 Arnaud Héritier<[email protected]>:
It doesn't seem so easy for me.
If we deploy 4.0.0 only we'll never be able to reuse new POMs in the build
process by inheritance for example.
Thus always deploying .pom artifacts as 4.0.0 keeps the compatibility but
won't allow us to evolve.
The problem is how to depend and how to extend (without talking about a
future : how to mix..)
On Tue, May 24, 2011 at 4:09 PM, John Casey<[email protected]> wrote:
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]
---------------------------------------------------------------------
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]
