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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
