Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: 2.0.7
-
Fix Version/s: None
-
Component/s: Deployment
-
Labels:None
-
Number of attachments :
Description
In a pom.xml I can use variables in almost any place that get resolved automatically and can even be declared in a parent POM.
This is an extremely cool feature! Now if for some reason I use variables in one of the following POM-attributes:
groupId
artifactId
version
they are NOT resolved when the pom.xml file is installed.
After having trouble with complex multi-module projects using individual module versioning I tried a new approach:
I define a global version as variable in the toplevel POM. All POMs that have packaging "pom" remain version 1.0 (unfortunately necessary because I can not only say <parent><relativePath>../pom.xml</relativePath></parent> - should be another feature request...).
It works surprisingly well: I do not need complex releas-plugins or whatever - I just change the central version property removing -SNAPSHOT, create a tag and then open development again by opening the successing SNAPSHOT version.
You might think that this is totally insane. However, it works fine. The only problem is that the repository can no more be used to get a different version anymore, even if the artifacts are there.
So all that is needed would be a specific rule in maven that resolves the variables in the stated sections of the POM when it is installed or deployed. If <parent><relativePath>../pom.xml</relativePath></parent> would also work locally then maven could also automatically fill in groupId, artifactId, and version of the parent POM during install/deploy.
If no variables are used, the suggested modification would have no effect. If variables are used, maven would be more reliable because the version could not change by some side-effect after an artifact is installed.
This issue seems to be almost a duplicate of MNG-2971
However it contains additional improvement suggestions.