[PROPOSAL] POM Version-Expression Transformation

[John Casey-5]

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 produce derivative files/metadata from a POM
that contains version expressions.

I've written up my thoughts on what exactly the problem is here, what I
see as our options for solving it, and how I think we ought to proceed.
You can find them here:

http://docs.codehaus.org/display/MAVEN/Transforming+POM+Version+Expressions

Please, read it over and let me know what you think. If you have a
completely different direction you think the solution should go, I want
to hear from you! If you have something you think I haven't considered
in this write-up, say so. I took a shot at fixing the version-expression
problem in 2.1.0, and opened up a pretty big bug for projects that want
GPG signatures of their POMs. I'd rather not repeat that mistake.

Thanks!

-john

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

[Arnaud HERITIER]

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 <jdcasey@...> wrote:

> 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
> produce derivative files/metadata from a POM that contains version
> expressions.
>
> I've written up my thoughts on what exactly the problem is here, what I see
> as our options for solving it, and how I think we ought to proceed. You can
> find them here:
>
> http://docs.codehaus.org/display/MAVEN/Transforming+POM+Version+Expressions
>
> Please, read it over and let me know what you think. If you have a
> completely different direction you think the solution should go, I want to
> hear from you! If you have something you think I haven't considered in this
> write-up, say so. I took a shot at fixing the version-expression problem in
> 2.1.0, and opened up a pretty big bug for projects that want GPG signatures
> of their POMs. I'd rather not repeat that mistake.
>
> Thanks!
>
> -john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Arnaud

[nicolas de loof-2]

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 subject of
your proposal, but with such a POM Transformation plugin attached to all
lifecycle we could open the POM format to enhancements (see for example the
current discution on apache-commons about commons-logging global exclusion,
or the proposal for an attribute-based 4.1.0 schema)

Cheers,
Nicolas



2009/5/19 Arnaud HERITIER <aheritier@...>

> 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 <jdcasey@...>
> wrote:
>
> > 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
> > produce derivative files/metadata from a POM that contains version
> > expressions.
> >
> > I've written up my thoughts on what exactly the problem is here, what I
> see
> > as our options for solving it, and how I think we ought to proceed. You
> can
> > find them here:
> >
> >
> http://docs.codehaus.org/display/MAVEN/Transforming+POM+Version+Expressions
> >
> > Please, read it over and let me know what you think. If you have a
> > completely different direction you think the solution should go, I want
> to
> > hear from you! If you have something you think I haven't considered in
> this
> > write-up, say so. I took a shot at fixing the version-expression problem
> in
> > 2.1.0, and opened up a pretty big bug for projects that want GPG
> signatures
> > of their POMs. I'd rather not repeat that mistake.
> >
> > Thanks!
> >
> > -john
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> --
> Arnaud
>

[John Casey-5]

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 it after that point.

Therefore, I've moved the code out of the ArtifactTransformation that
used to house it, and made it a separate component called
[Default]CoordinateInterpolator, which is called as the last step in
building a project instance from a POM in a project directory (not when
building from the local repository, though). This means that all plugins
referencing ${project.file} will get the same information, which should
be a lot less confusing. The interpolation step is pretty fast, so I
don't think it will be a major penalty for IDEs and such.

I've included an integration test to supplement the unit tests that were
adapted from the ArtifactTransformation code, and closed MNG-4167 and
MGPG-14 as a result.

-john

Arnaud HERITIER wrote:

> 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 <jdcasey@...> wrote:
>
>> 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
>> produce derivative files/metadata from a POM that contains version
>> expressions.
>>
>> I've written up my thoughts on what exactly the problem is here, what I see
>> as our options for solving it, and how I think we ought to proceed. You can
>> find them here:
>>
>> http://docs.codehaus.org/display/MAVEN/Transforming+POM+Version+Expressions
>>
>> Please, read it over and let me know what you think. If you have a
>> completely different direction you think the solution should go, I want to
>> hear from you! If you have something you think I haven't considered in this
>> write-up, say so. I took a shot at fixing the version-expression problem in
>> 2.1.0, and opened up a pretty big bug for projects that want GPG signatures
>> of their POMs. I'd rather not repeat that mistake.
>>
>> Thanks!
>>
>> -john
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>

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

[brettporter]

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, transformed as discussed, with minimal information  
from the POM required for resolution is deployed to the current  
location and the original POM (in whatever format) is pushed alongside  
it as part of the release - would it overcome the main issue? I'd need  
to refresh myself on the touchpoints.

- Brett

On 19/05/2009, at 12:45 PM, John Casey wrote:

> 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 produce  
> derivative files/metadata from a POM that contains version  
> expressions.
>
> I've written up my thoughts on what exactly the problem is here,  
> what I see as our options for solving it, and how I think we ought  
> to proceed. You can find them here:
>
> http://docs.codehaus.org/display/MAVEN/Transforming+POM+Version+Expressions
>
> Please, read it over and let me know what you think. If you have a  
> completely different direction you think the solution should go, I  
> want to hear from you! If you have something you think I haven't  
> considered in this write-up, say so. I took a shot at fixing the  
> version-expression problem in 2.1.0, and opened up a pretty big bug  
> for projects that want GPG signatures of their POMs. I'd rather not  
> repeat that mistake.
>
> Thanks!
>
> -john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

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