maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <bri...@infinity.nu>
Subject Re: POM 4+ was Re: Moving forward with mixins
Date Tue, 24 May 2011 12:25:45 GMT
2011/5/24 Arnaud Héritier <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 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.


> 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 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
>>
>>
>

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


Mime
View raw message