4

Our current pom file uses the keyword RELEASE for many of our dependencies, and we need to keep an artifact pom which contains the actual version that release corresponds to. Prepare-with-pom does this, and if I run maven with -DdryRun, I get a release-pom.xml that looks exactly correct.

However, for the real deal I need to remove the dry run and add the perform command. At this point maven does something weird. It fails every time with the following message:

The git-add command failed.
Command output:
fatal: pathspec 'release-pom.xml' did not match any files

A quick look through the most recent commands run shows:

[INFO] Executing: /bin/sh -c cd /Users/mikeburke/experience-manager/exm-v2 && git rm release-pom.xml
[INFO] Working directory: /Users/mikeburke/experience-manager/exm-v2
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /Users/mikeburke/experience-manager/exm-v2 && git add -- pom.xml release-pom.xml

Of course release-pom.xml isn't there, you just removed it.

So, why does this happen, and more importantly, how do I fix it? I've looked all through the forums and beyond, and the closest I've found to my problem is this, which recommends using various conflicting versions of maven and its dependencies, all of which I have tried. Has any one run this successfully, and can you help me please?

Community
  • 1
  • 1
IchabodE
  • 176
  • 3
  • 10

2 Answers2

3

This bug is recorded here: https://issues.apache.org/jira/browse/SCM-706

The patch was merged after org.apache.maven.scm:maven-scm-provider-gitexe:1.9.4 was cut so you'll have to install a snapshot from source or wait until 1.9.5 is released.

Trent Bartlem
  • 2,213
  • 1
  • 13
  • 22
1

After quite some effort trying to come up with a viable workaround, this is what I did:

  1. mvn release:prepare-with-pom -DdryRun=true This creates a release-pom.xml file with all the dependencies flattened, and with all the <version>RELEASE</version> tags replaced with actual versions.

  2. We opened our pom.xml and replaced the dependencies section with the one from release-pom.xml, and checked that in to source control.

  3. We now manually update the pom file whenever any of our internal jars update, and we re-run the above process anytime external dependencies change.

I was working on a bash script that Bamboo could run which would

  1. do a dry run
  2. rename pom.xml to pom.dev, and release-pom.xml to pom.xml
  3. run and tag the release build
  4. delete pom.xml and rename pom.dev to pom.xml
  5. update the snapshot version number and check things back in.

Due to the fact that I could never get proper dev/test time on our Bamboo server and the fact that I got different results running my script locally vs on the server, we ended up going with the simpler, more manual solution.

IchabodE
  • 176
  • 3
  • 10