> A minor problem could be in which sorting order to add from any
> imported ppom to the project. And how merging/overriding would look like if
> an imported ppom defines the same plugin GAV as the pom.
>
> ppoms can of course import other ppoms and build a hierarchy that way.
>
of course import other ppoms and build a hierarchy that way.
LieGrue,
strub
--- On Fri, 6/17/11, Brett Porter wrote:
> From: Brett Porter
> Subject: Re: Moving forward with mixins
> To: "Maven Developers List"
> Date: Friday, June 17, 2011, 12:11 AM
> (sorry for the del
On 6/16/11 8:11 PM, Brett Porter wrote:
(sorry for the delay, I've not forgotten, just been busy)
On 25/05/2011, at 12:34 AM, Jesse Glick wrote:
On 05/24/2011 01:30 AM, Brett Porter wrote:
Some notes on how I think it should work:
- templates should look like a normal POM (perhaps only diff
Hi Maurizio,
Re-reading this, I saw before we had a lot of agreement, but re-reading I see
you also had a question...
On 25/05/2011, at 1:44 AM, Maurizio Pillitu wrote:
>> However, I'm sure you're already noticing some limitations:
>> - you can't get in before interpolation, so properties used
(sorry for the delay, I've not forgotten, just been busy)
On 25/05/2011, at 12:34 AM, Jesse Glick wrote:
> On 05/24/2011 01:30 AM, Brett Porter wrote:
>> Some notes on how I think it should work:
>> - templates should look like a normal POM (perhaps only differing in root
>> element, and less st
On 5/25/11 3:48 AM, Stephen Connolly wrote:
On 25 May 2011 08:04, Jörg Schaible wrote:
John Casey wrote:
On 5/24/11 8:25 AM, Brian Fox wrote:
2011/5/24 Arnaud Héritier:
Before talking about a specific change in the model like the addition of
mixins (which may be cool but not critical) d
On 25 May 2011 08:04, Jörg Schaible wrote:
> John Casey wrote:
>
>>
>>
>> On 5/24/11 8:25 AM, Brian Fox wrote:
>>> 2011/5/24 Arnaud Héritier:
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
4+ was Re: Moving forward with mixins
> To: dev@maven.apache.org
> Date: Wednesday, May 25, 2011, 7:04 AM
> John Casey wrote:
>
> >
> >
> > On 5/24/11 8:25 AM, Brian Fox wrote:
> >> 2011/5/24 Arnaud Héritier:
> >>> Before talking about a specifi
John Casey wrote:
>
>
> On 5/24/11 8:25 AM, Brian Fox wrote:
>> 2011/5/24 Arnaud Héritier:
>>> 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 o
On Tue, May 24, 2011 at 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
>
I don't think classifier is the right use for this
We get it right this time w.r.t. extensions so that we don't have to
do this again! ;-)
2011/5/24 Arnaud Héritier :
> ok, but we'll deploy a new pom with a different classifier for each new
> version ?
> Whe we'll have 3 possible versions, how will we do ?
> If I 'm building a new project with a m
Hi Brett,
thanks for your positive feedback! My answers interleaved
> This is a good proof-of-concept, perhaps worth trying on some projects to
> see how it goes without needing to use a new Maven version.
>
I've tried already with the wicket-quickstart (one of the easiest archetypes
to tes
On 24 May 2011 16:30, nicolas de loof wrote:
> +1, simple and efficient
Well we still have to cache the fact that there is no pom with
classifier for any of the "old" artifacts...
But at MRM should be able to handle that / generate a map from the
"old" to the 5.0.0 model
>
> 2011/5/24 Stephen C
ok, but we'll deploy a new pom with a different classifier for each new
version ?
Whe we'll have 3 possible versions, how will we do ?
If I 'm building a new project with a maven compatible with POM 4.2.0 can I
extend a pom 4.0.0 or 4.1.0 ?
Said differently imagine we have a really new cool feature
On 24 May 2011 16:19, John Casey wrote:
> +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.
+1
>
> On
+1, simple and efficient
2011/5/24 Stephen Connolly
> 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 :
> > It doesn't seem so ea
+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 po
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 :
> It doesn't seem so easy for me.
> If we deploy 4.0.0 only we'll never be able to reuse new
The main issue with mixins is to define in which part of
the resolution mechanism we need to apply it and all the rules to override
or add entries in the POM
We need to provide flexibility but in an understandable way.
nowadays it is already difficult sometime to know why when the POM is
resolved w
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
>
> 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...
>
> Why only consider
On 05/24/2011 01:30 AM, Brett Porter wrote:
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) [...]
- any POM element is valid, other than
,
- templates need to be sourced fro
On 5/24/11 8:25 AM, Brian Fox wrote:
2011/5/24 Arnaud Héritier:
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 dy
Brett / Mark,
This all sounds great! I'm already dreaming of ways I could use this
functionality right now in my own builds...
Personally, I'm much more in favor of having separate template files in
the repository, since it helps keep the POMs associated with them lean,
and since it'll make
On Tue, May 24, 2011 at 3:05 PM, Brett Porter wrote:
>
> On 24/05/2011, at 10:12 PM, Arnaud Héritier wrote:
>
> > 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 man
On 24/05/2011, at 10:12 PM, Arnaud Héritier wrote:
> 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 in
On 24/05/2011, at 7:22 PM, Maurizio Pillitu wrote:
> Hi Mark,
>
> really interesting discussion indeed.
>
> I like very much your idea of including mixins within POM files; this
> weekend I did some code (which is actually very very similar to your
> description) and I ended up with something
2011/5/24 Arnaud Héritier :
> 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 tha
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
On 24/05/2011, at 7:09 PM, Mark Derricutt wrote:
> Great to see this being discussed.
>
>
> Initial thoughts that come to mind reading that you've got here ( which for
> the most part all looks good ).
Cool!
>
> You mentioned the possibility of having the templates inline, rather than
> I w
Hi Mark,
really interesting discussion indeed.
I like very much your idea of including mixins within POM files; this
weekend I did some code (which is actually very very similar to your
description) and I ended up with something working.
I've contributed my code to http://jira.codehaus.org/brows
Great to see this being discussed.
Initial thoughts that come to mind reading that you've got here ( which for
the most part all looks good ).
You mentioned the possibility of having the templates inline, rather than
I was wondering if using to be
consistent with and . If you have
multiple
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
33 matches
Mail list logo
