Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: neutral (nike.apache.org: 74.125.83.171 is neither permitted nor
 denied by domain of brianf@infinity.nu)
MIME-Version: 1.0
In-Reply-To: <BANLkTincf4LgD03EybkSBSys+kd2NKdK3w@mail.gmail.com>
References: <BANLkTincf4LgD03EybkSBSys+kd2NKdK3w@mail.gmail.com>
From: Brian Fox <brianf@infinity.nu>
Date: Tue, 24 May 2011 08:25:45 -0400
Message-ID: <BANLkTikOVT1V+TgyX4HECehJfMCDhG-PUQ@mail.gmail.com>
Subject: Re: POM 4+ was Re: Moving forward with mixins
To: Maven Developers List <dev@maven.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2011/5/24 Arnaud H=E9ritier <aheritier@gmail.com>:
> 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 d=
o 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.


> Arnaud
>
> On Tue, May 24, 2011 at 7:30 AM, Brett Porter <brett@apache.org> 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 ba=
sed
>> 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 fin=
d
>> 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 Dill=
on.
>> 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 roo=
t
>> element, and less strict validation requirements), so that normal valida=
tion
>> 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>
>> =A0<parent>
>> =A0 =A0...
>> =A0</parent>
>> =A0<templates>
>> =A0 =A0<template>
>> =A0 =A0 =A0<groupId>org.apache.maven.templates</groupId>
>> =A0 =A0 =A0<artifactId>maven-release-profile-template</artifactId>
>> =A0 =A0 =A0<version>1.0</version>
>> =A0 =A0 =A0<classifier>sources-and-javadocs</classifier> (optional eleme=
nt)
>> =A0 =A0</template>
>> =A0 =A0<template>
>> =A0 =A0 =A0<groupId>org.apache.maven.templates</groupId>
>> =A0 =A0 =A0<artifactId>maven-team-list</artifactId>
>> =A0 =A0 =A0<version>1.0</version>
>> =A0 =A0</template>
>> =A0</templates>
>> =A0...
>> </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/arti=
fact
>> 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
>>
>>
>

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