« Return to Thread: [PROPOSAL] POM Version-Expression Transformation
Re: [PROPOSAL] POM Version-Expression Transformation
by John Casey-5
::
Rate this Message:
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@...
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@...
« Return to Thread: [PROPOSAL] POM Version-Expression Transformation
| Free embeddable forum powered by Nabble | Forum Help |
