Skip to content

Commit

Permalink
[FIXED JENKINS-18272]
Browse files Browse the repository at this point in the history
Expose various key properties of POM as environment variables.
  • Loading branch information
kohsuke committed Oct 27, 2013
1 parent 2a7ff90 commit 59afb8b
Show file tree
Hide file tree
Showing 2 changed files with 39 additions and 1 deletion.
27 changes: 27 additions & 0 deletions src/main/java/hudson/maven/MavenModule.java
Expand Up @@ -323,6 +323,33 @@ public String getVersion() {
return version;
}

/**
* Packaging type of the module.
*
* pom, jar, maven-plugin, ejb, war, ear, rar, par or other custom types.
*
* @since 2.1
*/
public String getPackaging() {
return packaging;
}

/**
* Short-cut for {@code getModuleName().groupId}
* @since 2.1
*/
public String getGroupId() {
return getModuleName().groupId;
}

/**
* Short-cut for {@code getModuleName().artifactId}
* @since 2.1
*/
public String getArtifactId() {
return getModuleName().artifactId;
}

/**
* Gets the list of goals to execute for this module.
*/
Expand Down
13 changes: 12 additions & 1 deletion src/main/java/hudson/maven/MavenModuleSetBuild.java
Expand Up @@ -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.

Copy link
@kutzi

kutzi Nov 2, 2013

Member

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.

This comment has been minimized.

Copy link
@imod

imod Nov 17, 2013

Member

we should a some kind of documentation extension point, where plugins can register the ENV Vairables they contribute. the token-macro plugin already has something like this too...

This comment has been minimized.

Copy link
@jglick

jglick Nov 18, 2013

Member

env.html / env.groovy I think already exists for this purpose. Cannot recall details.

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.

Copy link
@jglick

jglick Jan 16, 2014

Member

Apparently caused JENKINS-21279.

This comment has been minimized.

Copy link
@jglick

jglick Feb 10, 2014

Member

@kohsuke do you intend to fix this or should someone else do it?

envs.put("POM_RELATIVEPATH", root.getRelativePath());
}

return envs;
}

Expand Down

8 comments on commit 59afb8b

@kutzi
Copy link
Member

@kutzi kutzi commented on 59afb8b Nov 2, 2013

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?

@jglick
Copy link
Member

@jglick jglick commented on 59afb8b Dec 16, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kutzi AFAIK @kohsuke is on vacation for a while, so I think you need to either make such a change yourself, or leave it alone (I doubt this would be a real source of confusion) and proceed with a 2.1 release.

@kohsuke
Copy link
Member Author

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.

@jtnord
Copy link
Member

@jtnord jtnord commented on 59afb8b Apr 28, 2014

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.

@gohonsen
Copy link

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.

@Cobraeti
Copy link

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:

  1. pre-build => POM_VERSION = initial snapshot version
  2. build => POM_VERSION = release version
  3. 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 😉

@Raketemensch
Copy link

@Raketemensch Raketemensch commented on 59afb8b May 2, 2017

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.

@Cobraeti
Copy link

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 from POM_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

  1. I don't remember where so I apologize for not quoting the guy who wrote this such useful trick on the comment I red 😖

Please sign in to comment.