-
Notifications
You must be signed in to change notification settings - Fork 194
Commit
Expose various key properties of POM as environment variables.
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -183,7 +183,18 @@ public EnvVars getEnvironment(TaskListener log) throws IOException, InterruptedE | |
mvn.buildEnvVars(envs); | ||
} | ||
} | ||
|
||
|
||
MavenModule root = getProject().getRootModule(); | ||
if (root!=null) {// I don't think it can ever be null but let's be defensive | ||
// TODO: this needs to be documented but where? | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
imod
Member
|
||
envs.put("POM_DISPLAYNAME", root.getDisplayName()); | ||
envs.put("POM_VERSION", root.getVersion()); | ||
envs.put("POM_GROUPID", root.getGroupId()); | ||
envs.put("POM_ARTIFACTID", root.getArtifactId()); | ||
envs.put("POM_PACKAGING", root.getPackaging()); | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong. |
||
envs.put("POM_RELATIVEPATH", root.getRelativePath()); | ||
} | ||
|
||
return envs; | ||
} | ||
|
||
|
8 comments
on commit 59afb8b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what about multi-module builds?
Since this only includes the POM properties of the root POM (which by itself is fine for me), we should IMO make this clear in the env vars names. E.g. ROOT_POM_ARTIFACTID
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand @kutzi 's reasoning, but (1) for compatibility it's easier not to rename them and (2) I'm not sure how to name environment variables if we are to expose them from other modules, so I'm inclined to just stick to this and not worry about multi-module builds.
At some point I feel like this is Maven's job to provide tooling to extract these information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getEnvironment() is called before the code checkout and parsing of the POMs if I am not mistaken.
As such this will just return the info for the previous which will could cause unexpected confusion of users esp so when using a release plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When choose "Perform Maven Release" , how can I get "Release Version" and "Development version" ? "POM_VERSION" is not I wanted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
Same problem as @gohonsen: it would be interesting to have at least the POM_VERSION updated with the release version when performing a maven release.
But for something more relevent, it would be a must to have this behavior:
- pre-build => POM_VERSION = initial snapshot version
- build => POM_VERSION = release version
- post-build => POM_VERSION = new snapshot version
I will try to find a trick with other environment variables for my current project, but I hope this idea could help others in a later time 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to access developerConnection? Or perhaps to make all of the standard properties available? Getting the tag URL that is created during the build would be incredibly handy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
Thanks to @Raketemensch's comment I realised that I haven't shared my workaround.
I found1 that there is an environment variable named MVN_RELEASE_VERSION
that could be checked:
- if it is empty/null, you are not performing a maven release and you should read the current version from
POM_VERSION
- if it is not, you are performing a maven release and you should read the release version from
MVN_RELEASE_VERSION
and the corresponding snapshot version fromPOM_VERSION
if needed (but not the next snapshot version that will be prepared for "the next development iteration")
Here is the bash test I wrote, in case it could help anyone:
VERSION="$POM_VERSION"
IS_RELEASE=false
if [[ $MVN_RELEASE_VERSION != "" ]]
then
IS_RELEASE=true
VERSION="$MVN_RELEASE_VERSION"
fi
if [[ $IS_RELEASE = true ]]
then
# Do what you want for releases
else
# Do what you want for non-releases (so technically snapshots...)
fi
Footnotes
-
I don't remember where so I apologize for not quoting the guy who wrote this such useful trick on the comment I red 😖 ↩
Well one point to start documenting this, would be the Wiki ;-)
Wouldn't hurt to have this as a help page for the maven build step, either.