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
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
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 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
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
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
19 matches
Mail list logo
