You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jörg Hohwiller <jo...@j-hohwiller.de> on 2010/07/11 16:13:40 UTC
Maven variables and install/deploy POM
Hi there,
Since Maven 2.1 you can define variables in profile.xml
However when the POM is installed or even deployed, these
variables are not replaced.
Now when POM is installed or deployed, the variables
from profle (settings.xml and profile.xml) need to be
replaced with the actual values.
Otherwise the whole mechanism turns useless.
Currently you end up with something like
myArtifactId-1.0.0.pom:
<project>
<artifactId>myArtifactId</artifactId>
<version>${myArtifactIdVersion}</version>
...
</project>
Something like this is totally non-sense in
central repo or where ever as the value for
"myArtifactIdVersion" is on my local disc and
not accessible by the rest of the word.
IMHO artifactId, groupId and version of project and
its parent should be resolved in any case when
POM is installed/deployed. For dependencies
this should only apply if variables are not
defined in the POM itself (and maybe even
if inherited from parent).
Where is the right place to address such "fix"?
Wasn't there are mechanism in maven 2.1.x (maybe preview)
that copies pom.xml to target/pom-transformed.xml?
Is there any chance to get this into 2.2.x or
what is the real road-map for 3.x (alpha is released
but official release might still take a very long
way to got)?
As MNG-624 shows it seems not enough to supply a patch
as Ralph's work was simply a waste of time and
his patch is rejected. So I am careful before
investing a lot of time. Anyhow I am sick of hacking
my own dirty MOJOs again in various projects to have
strange workarounds for this problem.
If you look at the number of issues around this and
comments and votes there is quite a reasonable demand
for better support in this area...
To me the core thing is still the good old issue:
http://jira.codehaus.org/browse/MNG-2971
and somehow:
http://jira.codehaus.org/browse/MNG-3782
However for the big picture of maintaining large maven-projects
(esp. versions of project-internal modules) this is the last
blocker...
See also:
http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
Thanks
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven variables and install/deploy POM
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
Hi Brett,
thanks for your response.
>> Wasn't there are mechanism in maven 2.1.x (maybe preview)
>> that copies pom.xml to target/pom-transformed.xml?
>
> Yes, but it caused problems:
> http://jira.codehaus.org/browse/MNG-4223
Ah. Good to know.
>
>>
>> Is there any chance to get this into 2.2.x or
>> what is the real road-map for 3.x (alpha is released
>> but official release might still take a very long
>> way to got)?
>
> If you can come up with a proposal that overcomes the issues and are willing
> to see it through it could certainly be included in 3.x.
I thought my suggestion is rather obvious. What do you expect as a "proposal".
An Issue?
I think they already exist in jira.
Or something like my last one?
http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
IMHO it is some sort of a bug that
foo-2.1.7.pom is installed/deployed with
<version>${myVersion]</version>
instead of
<version>2.1.7</version>
That's almost everything about it.
For a general solution about where else in POM variables should be resolved,
there might be more to discuss. I alredy pointed some things out about this.
>
> It might be a candidate for considering with other POM changes in 3.1...
>
> - Brett
Regards
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven variables and install/deploy POM
Posted by Brett Porter <br...@apache.org>.
On 12/07/2010, at 12:13 AM, Jörg Hohwiller wrote:
> Wasn't there are mechanism in maven 2.1.x (maybe preview)
> that copies pom.xml to target/pom-transformed.xml?
Yes, but it caused problems:
http://jira.codehaus.org/browse/MNG-4223
>
> Is there any chance to get this into 2.2.x or
> what is the real road-map for 3.x (alpha is released
> but official release might still take a very long
> way to got)?
If you can come up with a proposal that overcomes the issues and are willing to see it through it could certainly be included in 3.x.
It might be a candidate for considering with other POM changes in 3.1...
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven variables and install/deploy POM
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
Hi again,
to make my point of view clear, I tend to exaggerate
and after reading this mail again, I noticed that
it is kind of harsh.
Sorry for that. After all my personal struggles with maven
it is still the best tool around the java ecosystem I
have ever seen.
Maven created a big shift into the entire java community
from messy lib-directories with undefined JAR-files and
unstructured build-scripts into a consistent
world.
I love maven and the one you love is somehow the one you
assault most...
Thanks for all your effort in maven and never give up!
Take care
Jörg
> Hi there,
>
> Since Maven 2.1 you can define variables in profile.xml
> However when the POM is installed or even deployed, these
> variables are not replaced.
>
> Now when POM is installed or deployed, the variables
> from profle (settings.xml and profile.xml) need to be
> replaced with the actual values.
> Otherwise the whole mechanism turns useless.
> Currently you end up with something like
> myArtifactId-1.0.0.pom:
> <project>
> <artifactId>myArtifactId</artifactId>
> <version>${myArtifactIdVersion}</version>
> ...
> </project>
>
> Something like this is totally non-sense in
> central repo or where ever as the value for
> "myArtifactIdVersion" is on my local disc and
> not accessible by the rest of the word.
>
> IMHO artifactId, groupId and version of project and
> its parent should be resolved in any case when
> POM is installed/deployed. For dependencies
> this should only apply if variables are not
> defined in the POM itself (and maybe even
> if inherited from parent).
>
> Where is the right place to address such "fix"?
>
> Wasn't there are mechanism in maven 2.1.x (maybe preview)
> that copies pom.xml to target/pom-transformed.xml?
>
> Is there any chance to get this into 2.2.x or
> what is the real road-map for 3.x (alpha is released
> but official release might still take a very long
> way to got)?
>
> As MNG-624 shows it seems not enough to supply a patch
> as Ralph's work was simply a waste of time and
> his patch is rejected. So I am careful before
> investing a lot of time. Anyhow I am sick of hacking
> my own dirty MOJOs again in various projects to have
> strange workarounds for this problem.
> If you look at the number of issues around this and
> comments and votes there is quite a reasonable demand
> for better support in this area...
>
> To me the core thing is still the good old issue:
> http://jira.codehaus.org/browse/MNG-2971
> and somehow:
> http://jira.codehaus.org/browse/MNG-3782
>
> However for the big picture of maintaining large maven-projects
> (esp. versions of project-internal modules) this is the last
> blocker...
>
> See also:
> http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
>
> Thanks
> Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org