Does this page need to be marked out of date since it was pulled from
2.2.0?
I was also thinking further about this - what extent would separating
the resolution metadata in the repository from the POM help?
I think this has been mentioned before - so if a 4.0.0 POM in the
current format,
After talking at length to Brian and Jason about this, it became obvious
that injecting this logic into the build process at some arbitrary point
in the lifecycle would probably only increase confusion, since binding a
given plugin before that point would produce different results than
binding
I like the idea to have a new plugin normalize the POM before it gets
installed / deployed
This could be used also to translate the project POM from another XML schema
version / alternative language (groovy, json, or whatever) to 4.0.0
retro-compatible POM before beeing made public. This is not the
Thx a lot John for this good sum-up about this issue.Seing your thoughts
about how to fix it, I understand that we have few solutions.
You are talking about Maven 3.0. How will it handle this case ?
Can't we reuse something from it ?
Arnaud
On Tue, May 19, 2009 at 4:45 AM, John Casey wrote:
> I
I've been grappling with version-expression interpolation since before
Maven 2.1.0 (See MNG-3057, MNG-4140, and now MNG-4167). It seems that
doing this transformation within an ArtifactTransformation
implementation is a flawed concept, since it means that plugins are
using old content when they
