of course import other ppoms and build a hierarchy that way.
LieGrue,
strub
--- On Fri, 6/17/11, Brett Porter br...@apache.org wrote:
From: Brett Porter br...@apache.org
Subject: Re: Moving forward with mixins
To: Maven Developers List dev@maven.apache.org
Date: Friday, June 17, 2011, 12:11 AM
--- On Fri, 6/17/11, Brett Porter br...@apache.org wrote:
From: Brett Porter br...@apache.org
Subject: Re: Moving forward with mixins
To: Maven Developers List dev@maven.apache.org
Date: Friday, June 17, 2011, 12:11 AM
(sorry for the delay, I've not
forgotten, just been busy)
On 25/05/2011
(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 strict
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
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
John Casey wrote:
On 5/24/11 8:25 AM, Brian Fox wrote:
2011/5/24 Arnaud Héritieraherit...@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
joerg.schai...@scalaris.com
Subject: Re: POM 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éritieraherit...@gmail.com:
Before talking about a specific
On 25 May 2011 08:04, Jörg Schaible joerg.schai...@scalaris.com wrote:
John Casey wrote:
On 5/24/11 8:25 AM, Brian Fox wrote:
2011/5/24 Arnaud Héritieraherit...@gmail.com:
Before talking about a specific change in the model like the addition of
mixins (which may be cool but not critical)
On 5/25/11 3:48 AM, Stephen Connolly wrote:
On 25 May 2011 08:04, Jörg Schaiblejoerg.schai...@scalaris.com wrote:
John Casey wrote:
On 5/24/11 8:25 AM, Brian Fox wrote:
2011/5/24 Arnaud Héritieraherit...@gmail.com:
Before talking about a specific change in the model like the addition
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
templateSpecs I was wondering if using templateManagement to be
consistent
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
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
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
2011/5/24 Arnaud Héritier aherit...@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
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
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
On Tue, May 24, 2011 at 3:05 PM, Brett Porter br...@apache.org 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
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 5/24/11 8:25 AM, Brian Fox wrote:
2011/5/24 Arnaud Héritieraherit...@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
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
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
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
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
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 aherit...@gmail.com:
It doesn't seem so easy for me.
If we deploy 4.0.0 only we'll never be
+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
+1, simple and efficient
2011/5/24 Stephen Connolly stephen.alan.conno...@gmail.com
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
On 24 May 2011 16:19, John Casey jdca...@commonjava.org 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
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
On 24 May 2011 16:30, nicolas de loof nicolas.del...@gmail.com 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
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 test)
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 aherit...@gmail.com:
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
On Tue, May 24, 2011 at 11:17 AM, Stephen Connolly
stephen.alan.conno...@gmail.com 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
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
33 matches
Mail list logo
