maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: POM 4+ was Re: Moving forward with mixins
Date Tue, 24 May 2011 15:17:49 GMT
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 <aheritier@gmail.com>:
> 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 <jdcasey@commonjava.org> wrote:
>
>>
>>
>> On 5/24/11 8:25 AM, Brian Fox wrote:
>>
>>> 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.
>>>
>>
>> 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<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
>>>
>>>
>> --
>> 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
>>
>>
>

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


Mime
View raw message