-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle SNAPSHOT versions in with overrideWar
#478
Conversation
if the war scanning encounters a SNAPSHOT build of a plugin then then manifest file will contain a `Plugin-Version` entry like `1.2.3-4-SNAPSHOT (private abcd1234-username)`. This causes a failure when updating the dependencies as the plugin will try and use that directly without stripping off the extra parts. THis strips off any extra parts should they be present so that the version number matches a valid maven version number and also emits a warning to the log about non repeatable builds if any snapshots are encountered.
overrideWar
@@ -517,8 +517,7 @@ private static void appendEntries(String property, Collection<String> additions, | |||
* @param war The WAR to scan. | |||
* @return The bundled plugins in the WAR. | |||
*/ | |||
private static Map<String, String> scanWar(File war, MavenSession session, MavenProject project) | |||
throws MojoExecutionException { | |||
private Map<String, String> scanWar(File war) throws MojoExecutionException { |
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.
getLog()
is set for the mojo object, so this needs to be non-static. the MavenSession
and MavenProject
are already set in the Mojo - so these are used directly.
@@ -550,6 +549,12 @@ private static Map<String, String> scanWar(File war, MavenSession session, Maven | |||
if (version == null) { | |||
throw new IllegalArgumentException("Failed to determine version for " + name); | |||
} | |||
// handle any extra info in snapshots e.g. " (private-abcd1234-username)" |
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.
Whilst we could use Implementation-Version
and then fall back - some plugins (gradle
) do not provide this due to tooling or being too old (this was added approx. 2 years ago). Given the need to fallback, it is easier just to handle the legacy case here.
src/main/java/org/jenkinsci/maven/plugins/hpi/TestDependencyMojo.java
Outdated
Show resolved
Hide resolved
…jo.java Co-authored-by: Basil Crow <me@basilcrow.com>
if the war scanning encounters a SNAPSHOT build of a plugin then then manifest file will contain a
Plugin-Version
entry like1.2.3-4-SNAPSHOT (private abcd1234-username)
.This causes a failure when updating the dependencies (
resolve-test-dependencies
) as the plugin will try and use that directly without stripping off the extra parts.This strips off any extra parts should they be present so that the version number matches a valid maven version number and also emits a warning to the log about non repeatable builds if any snapshots are encountered.
Testing done
manually tested with a war containing a snapshot using the command
mvn.cmd -B -V -e -DoverrideWar=C:\workarea\myWarWithSnapshot.war -Djenkins.version=2.387.3-cb-2 -DuseUpperBounds=true org.jenkins-ci.tools:maven-hpi-plugin:3.44-20230503.112206-2:resolve-test-dependencies
mojo no longer fails and the log is present in the output
IT in #480
Submitter checklist