release-version.sh failing on Windows Git Bash #49
Comments
|
Oh, interesting and might be related 👀: |
|
For ... and for the latest release So given the discussion linked in my previous comment, I assume this should be fixed if we bump our dependency in |
|
🚀 pinning the version property For example: |
|
@imagejan Cool, glad you found a workaround! 👍 How about if we had this hack to 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:
Thoughts? |
|
Thanks, Curtis. Yes, this hack in |
|
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. |
|
Closing this, with the assumption that projects extending pom-scijava 34+ are now OK. Please reopen if not. |
As mentioned in ijpb/MorphoLibJ#62 (comment), it seems there's a general issue with
release-version.shwhen used in Git Bash. I was now able to reproduce the behavior inimagej-plugins-search-biiiand get the following output:Full output of release-version.sh
It looks like the maven release plugin finishes release preparation successfully, and the respective changes were committed locally:
So it seems the script is running until here:
scijava-scripts/release-version.sh
Lines 333 to 337 in 224ea62
... but then maven returns a non-zero exit code?!
Indeed, runnning:
... results in:
@ctrueden any ideas?
The text was updated successfully, but these errors were encountered: