Variables are not replaced into installed pom file

not sure it's related to the install plugin. This sounds like a bad practice to me.

Yep, seems to be a problem, using properties from settings.xml in version tags or dependencies does not expand the variables and maven creates $

folder in the repository instead of real version.

I created almost the same issue MNG-3267
The specific scenario described in MNG-3267 is indeed bad practice but just a workaround for a real problem with maven.
Anyhow using variables for versions is NOT generally a bad practice!!!
If you ever managed a really big multiproject with maven (with 3 or more levels and with hundreds of modules)
you will discover that using explicit versions will drive you crazy, are extremely error prone and maven-release-plugin is no help.

So, what is a best practice? I've got the same problem. Managing versions in a large multi-module project is really time consuming. I'd like to have just one place to change the version and not to change all poms in my project to modify parent links.

Using maven 2.0.8, we still have the problem with the <parent> tag.

<parent>
<groupId>com.mycompany.odp</groupId>
<artifactId>ocs-core</artifactId>
<version>$

</version>
</parent>

Properties in "project.parent.version" do NOT get substituted but properties in "project.version" do.
We are on the process of migrating our 900 artifacts project to maven. Most of those artifacts will share the same release version and inherit from the same parent, so it is out of question to do a "search and replace".

Looks like a substitution bug to me.
For the moment, it is a show stopper for us that blocks the migration of our 900 artifacts.

similar issue.

Reopening since after re-reading it doesn't seem to actually be a duplicate. However, I'm not sure the reported problem will ever be addressed.

Until the install plugin is fixed, there is the following workaround:

You first replace the variables in the pom during the build process by using the assembly plugin
and install the modified file afterwards over the orginal pom.

Modified pom:

<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution><!-- Replace the placeholder of the pom by their values (used by the install plugin below)-->
<id>replace-pom-placeholder</id>
<phase>package</phase>
<goals><goal>single</goal></goals>
<configuration>
<finalName>modified-pom</finalName>
<descriptors>
<descriptor>src/assemble/replacePomPlaceholder.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>

<plugin>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution><!-- Replaces the pom (with placeholders) in the repository with the pom without placeholders -->
<id>overwrite-pom</id>
<phase>install</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<file>target/modified-pom-replacePomPlaceholder/modified-pom/pom.xml</file>
<pomFile>target/modified-pom-replacePomPlaceholder/modified-pom/pom.xml</pomFile>
</configuration>
</execution>
</executions>
</plugin>

Assembly Descriptor replacePomPlaceholder.xml

<assembly>

<id>replacePomPlaceholder</id>
<formats>
<format>dir</format>
</formats>

<files>
<file>
<source>pom.xml</source>
<outputDirectory>/</outputDirectory>
<filtered>true</filtered>
</file>
</files>

</assembly>

expressions in <version> elements within the POM are interpolated since Maven 2.1.0. I've actually just introduced some more code to improve that behavior. Is the above problem still present in 2.1.0??

Jep. I just retested this with maven 2.1.0. I still see the variables in the installed pom.
I also tried the latest released install-plugin.

For those who want to be able to manage versions dynamically it makes sense for variables to be replaced dynamically in the installed POMs.

At the very least the installed POMs should be stamped with the variable value at install time. This half way result of having the placeholders still present in the installed POM is of no use to anyone.

Are there any plans to support either of these features?

Good point, Gavin. I also voted for this issue, but you are right. It might be a bad idea to let maven figure out what you want by some magic. But if the variable is NOT defined in the POM itself (including inheritance from parent POMs) then it cant be wrong to replace the
variable because otherwise the installed POM is bad.
Another way to solve this properly is maybe some command line option to activate this feature. But then you still would not have both ways at a time. An additional tag in <dependency> as trigger, that is stripped when installed, is also a possibility.

I also opened MNG-4161 so maybe that is a different solution that mainly addresses the same problem if someone cares or wants to vote for.

How does this relate to MNG-3057?
Is this a duplicate? Why was MNG-3057 closed? I am puzzled.
Can someone bring light into this?

We have a fairly complex maven environment and without Christian's workaround, we would have been dead in the water. I also agree that installing poms with unexpanded properties is useless.

This is also a problem for us as far as versions are concerned. Would it be feasible to at least replace the versions in installed poms?

This is a blocker issue for us to migrate from ANT. I voted for this issue to be fixed in the install plugin...

Please also read MNG-624 - this issue is really important for many users.
Maven has the philosophy "convention over configuration", so in such cases we should avoid ending up with "workaround over usability".

Hi,

Do you have any updates on this issue? If it is not going to fix this issue in near future, could you please give the workaround for this at the earliest?

Thanks and Regards,
Kannan

IMO, the right fix would be to allow "controlled" property expansion of user defined properties via the maven-install-plugin, a la the latest ant filter <expandproperties regex=".*\.version$"/>, as you definitely do NOT want to expand $

or $

etc. maven-install-plugin probably should expand anything in <version> elements by default.

Right now, my workaround is to use maven-antrun-plugin to sanitize the poms before install. The maven-assembly-plugin filter workaround would not work for me as it expands all the properties.

Hey Luke, would you mind sharing the antrun configuration section of your pom with us?

I have this problem in my project. Is there any fix for this issue?

That happens to me creating a project from an archetype from my company. Even having the parameters required in the archeype-metadata.xml and passing them on mvn archetype:generate, the resulting pom has not the parameters (groupId, artifactId...) replaced

This is the output from mvn archetype:generate:

Using following parameters for creating project from Archetype: mygroup-archetype:1.0-SNAPSHOT
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: groupId, Value: org.myorg.mygroup.myproject
[INFO] Parameter: artifactId, Value: myproject
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: package, Value: org.myorg.mygroup
[INFO] Parameter: packageInPathFormat, Value: org/myorg/mygroup
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: package, Value: org.myorg.mygroup
[INFO] Parameter: groupId, Value: org.myorg.mygroup.myproject
[INFO] Parameter: artifactId, Value: myproject

this is the generated project's pom file:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>$org.myorg.mygroup</groupId>
<artifactId>$mygroup-archetype</artifactId>
<version>$1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>

this is a section of the archetype-metadata.xml for my company's archetype

<archetype-descriptor
xmlns="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0 http://maven.apache.org/xsd/archetype-descriptor-1.0.0.xsd"
name="mygroup-archetype" partial="false">

<requiredProperties>
<requiredProperty key="artifactId" />
<requiredProperty key="groupId" />
<requiredProperty key="package" />
</requiredProperties>

<fileSets>
<fileSet filtered="true" packaged="true">
<directory>src/main/java</directory>
<includes>
<include>*/.java</include>
</includes>
</fileSet>

<fileSet filtered="true" packaged="true">
<directory>src/test/java/</directory>
<includes>
<include>*/.java</include>
</includes>
</fileSet>

<fileSet filtered="true" packaged="true">
<directory>/src/main/generated</directory>
<includes>
<include>*/.java</include>
</includes>
</fileSet>
...
</<archetype-descriptor>

Since this issue is 6 years old, maybe it's useful to give use-cases as to why one would want to do this.

This thread discusses why myself and others would like to variablize the version field (summary; to create a scheme where the SCM is the primary source of version info)

http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tc5543110.html

Hi. I noticed that MNG-4223, which is already related to this issue, seems to be much more researched. Strictly speaking it is a restricted version of this, because it cares only about the artifact coordinate tags with regards to property expansion and not the whole POM. However, since the description of this issue exemplifies the problem with the <version> tag I think that probably the artifact coordinates are all this issue's reporter cares about.

Is that so?

If it is, I think it would be a good idea to close this issue marking it as a duplicate of MNG-4223 in order to focus the efforts towards a solution.

@Christian Bauer - Just wanted to say thanks, just what I needed.

In case others are having the same problems with multi-module projects, I needed to make one small change for ear/war pom configs.
Under maven-install-plugin configuration, be sure to change <file></file> to the proper ear/war locations respectively.

ex:
<configuration>
<file>target/$

-$

.war</file>
<pomFile>target/modified-pom-replacePomPlaceholder/modified-pom/pom.xml</pomFile>
</configuration>

Please also consider this reply a +1 for substitutions in the parent configuration.

<parent>
<groupId>com.example</groupId>
<artifactId>artifact</artifactId>
<version>$

</version>
</parent>

I'm recommending an alternative syntax for "to-be-replaced" variables at install/deploy time. There are now projects that heavily depend on variables now because of the glitch.

Is there any rationale beyond placing the same pom in the repository instead of effective pom?

We need this for a multi-module build. We want to specify that some sibling module dependencies have the same version as the parent or current project. If we do this:

<dependency>
<groupId>com.example</groupId>
<artifactId>common</artifactId>
<version>$

</version>
<scope>compile</scope>
</dependency>

then the varible appears in the installed pom and then can't be used by anything.

Currently - like most people - we have a pre-build step which sets all versions accross the whole tree.

Putting this functionality into the release plugin would be completely useless as the release plugin simply doesn't do the right thing for CI style builds where the version is set from the build number/scm revision etc.