release-version.sh failing on Windows Git Bash about scijava-scripts

[ctrueden]

OK, just for completeness, I did work up a version of this patch that only forces the maven-release-plugin version if it's too old:

diff --git a/release-version.sh b/release-version.sh
index 197ebe3..366ada5 100755
--- a/release-version.sh
+++ b/release-version.sh
@@ -30,6 +30,11 @@ no_changes_pending() {
 	git diff-index --cached --quiet --ignore-submodules HEAD --
 }
 
+mavenEvaluate() {
+	result=$(mvn -B -q -Denforcer.skip=true -Dexec.executable=echo -Dexec.args="$1" --non-recursive validate exec:exec 2>&1)
+	test $? -eq 0 && echo "$result" || mvn -B -U -q -Denforcer.skip=true -Dexec.executable=echo -Dexec.args="$1" --non-recursive validate exec:exec 2>&1
+}
+
 # -- Constants and settings --
 
 SCIJAVA_BASE_REPOSITORY=-DaltDeploymentRepository=scijava.releases::default::dav:https://maven.scijava.org/content/repositories
@@ -118,16 +123,16 @@ Options include:
 # -- Extract project details --
 debug "Extracting project details"
 
-echoArg='${project.version}:${license.licenseName}:${project.parent.groupId}:${project.parent.artifactId}:${project.parent.version}'
-projectDetails=$(mvn -N -Dexec.executable=echo -Dexec.args="$echoArg" exec:exec -q)
-test $? -eq 0 || projectDetails=$(mvn -U -N -Dexec.executable=echo -Dexec.args="$echoArg" exec:exec -q)
+projectDetails=$(mavenEvaluate '${project.version}:${license.licenseName}:${project.parent.groupId}:${project.parent.artifactId}:${project.parent.version}:${maven-release-plugin.version}')
 test $? -eq 0 || die "Could not extract version from pom.xml. Error follows:\n$projectDetails"
 echo "$projectDetails" | grep -Fqv '[ERROR]' ||
 	die "Error extracting version from pom.xml. Error follows:\n$projectDetails"
 currentVersion=${projectDetails%%:*}
 projectDetails=${projectDetails#*:}
 licenseName=${projectDetails%%:*}
-parentGAV=${projectDetails#*:}
+projectDetails=${projectDetails#*:}
+parentGAV=${projectDetails%%:*}
+releasePluginVersion=${projectDetails#*:}
 
 # -- Sanity checks --
 debug "Performing sanity checks"
@@ -328,10 +333,27 @@ exclude them by setting license.excludes in your POM; e.g.:
 Alternately, try again with the --skip-license-update flag.'
 }
 
+# Work around issue with the maven-release-plugin on Windows Git Bash.
+# See: https://github.com/scijava/scijava-scripts/issues/49
+WORKAROUNDS=
+case "$(uname -s 2> /dev/null)" in
+	MINGW*)
+		case "$releasePluginVersion" in
+			0.*|1.*|2.*)
+				echo "--> Forcing maven-release-plugin version from $releasePluginVersion to 3.0.0-M7"
+				WORKAROUNDS=-Dmaven-release-plugin.version=3.0.0-M7
+				;;
+			*)
+				echo "--> maven-release-plugin version OK: $releasePluginVersion"
+				;;
+		esac
+		;;
+esac
+
 # Prepare new release without pushing (requires the release plugin >= 2.1).
 debug "Preparing new release"
 $DRY_RUN mvn $BATCH_MODE release:prepare -DpushChanges=false -Dresume=false $TAG \
-        $PROFILE $DEV_VERSION -DreleaseVersion="$VERSION" \
+	$PROFILE $WORKAROUNDS $DEV_VERSION -DreleaseVersion="$VERSION" \
 	"-Darguments=-Dgpg.skip=true ${EXTRA_ARGS# }" ||
 	die 'The release preparation step failed -- look above for errors and fix them.
 Use "mvn javadoc:javadoc | grep error" to check for javadoc syntax errors.'

But I won't apply it now, in favor of the anticipated pom-scijava 34 release.

[ctrueden]

Closing this, with the assumption that projects extending pom-scijava 34+ are now OK. Please reopen if not.

[imagejan]

Oh, interesting and might be related 👀:

mojohaus/versions#483

[imagejan]

For maven-release-plugin at version 2.5.3' (the version currently managed by pom-scijava-base`, I get:

$ mvn dependency:tree | grep interactivity
[INFO] |  +- org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-6:compile

... and for the latest release maven-release-plugin-3.0.0-M7:

$ mvn dependency:tree | grep interactivity
[INFO] |  +- org.codehaus.plexus:plexus-interactivity-api:jar:1.1:compile

So given the discussion linked in my previous comment, I assume this should be fixed if we bump our dependency in pom-scijava-base to that version.

[imagejan]

🚀 pinning the version property <maven-release-plugin.version>3.0.0-M7</maven-release-plugin.version> works around this issue in any downstream project:

For example:
imagej/imagej-plugins-search-biii@caa181c

[ctrueden]

@imagejan Cool, glad you found a workaround! 👍 How about if we had this hack to release-version.sh instead of changing the pom.xml files of projects being released in this way? Something like:

diff --git a/release-version.sh b/release-version.sh
index 197ebe3..2c80ba6 100755
--- a/release-version.sh
+++ b/release-version.sh
@@ -328,10 +328,16 @@ exclude them by setting license.excludes in your POM; e.g.:
 Alternately, try again with the --skip-license-update flag.'
 }
 
+# Work around issue with the maven-release-plugin on Windows Git Bash.
+RELEASE_HACK=
+case "$(uname -s 2> /dev/null)" in
+	MINGW*) RELEASE_HACK=-Dmaven-release-plugin.version=3.0.0-M7 ;;
+esac
+
 # Prepare new release without pushing (requires the release plugin >= 2.1).
 debug "Preparing new release"
 $DRY_RUN mvn $BATCH_MODE release:prepare -DpushChanges=false -Dresume=false $TAG \
-        $PROFILE $DEV_VERSION -DreleaseVersion="$VERSION" \
+	$PROFILE $RELEASE_HACK $DEV_VERSION -DreleaseVersion="$VERSION" \
 	"-Darguments=-Dgpg.skip=true ${EXTRA_ARGS# }" ||
 	die 'The release preparation step failed -- look above for errors and fix them.
 Use "mvn javadoc:javadoc | grep error" to check for javadoc syntax errors.'

A couple of concerns though:

1. I didn't test it. 😉 So it might be necessary, instead or in addition, to do:

   EXTRA_ARGS=" $EXTRA_ARGS -Dmaven-release-plugin.version=3.0.0-M7"

   so that the argument gets passed into the nested -Darguments of the build as well? (I'm guessing not, but maybe...)
2. Once a newer version than 3.0.0-M7 is released, this hack would continue pinning it to the then-not-newest milestone release, which is probably undesirable. So maybe the hack should check first, similar to how the ci-build.sh script upgrades the maven-gpg-plugin if it is too old.

Thoughts?

[imagejan]

Thanks, Curtis. Yes, this hack in release-version.sh would probably make it better at once for all Git Bash users. I'm just afraid of the increased maintenance burden on the scijava-scripts side (i.e. on you) then.
If a new release of pom-scijava-base (with scijava/pom-scijava-base#33) and pom-scijava is around the corner, this would be a more sustainable solution IMHO, as release-version.sh anyways checks if the parent POM is up to date, so people upgrade and benefit from the change.