21

Is there a way to avoid merge conflicts in version tag in pom.xml when merging master into a branch? I have quite a few pom files, 80, and all of them have same version which is different from one in master. It's laborious and time-consuming to execute git mergetool for 80 pom files just for a version tag.

Gilles 'SO- stop being evil'
  • 104,111
  • 38
  • 209
  • 254
Abidi
  • 7,846
  • 14
  • 43
  • 65
  • I would also recommend, about maven, to have a specific pom for your versions, so that when you change the version, you don't have to update all your files. – Vince Aug 30 '12 at 13:32
  • 3
    The previous comment does not address the question. It's not to do with *dependency* versions. It's to do with the version of the software you're building being in the `pom.xml` file. This is an issue because we're storing metadata about the version in a file that any SCM has to deal with. Merges then become complicated. – Stephen Harrison Aug 25 '15 at 14:36

7 Answers7

10

What I always do is change the version of the modules using the maven versions plugin, before merging from another branch (with a different version):

mvn versions:set -DnewVersion=1.1 -DgenerateBackupPoms=false

That'll change the version of all the current modules (parent and children) to the one you specify as the newVersion parameter. After changing the version, make a new commit (git commit...) and then do the merge. I've got all of this automated using a Jenkins task, but it shouldn't be difficult to implement it in other ways (e.g. sh script).

emerino
  • 1,100
  • 11
  • 17
8

You probably have a few options. None of which are perfect :-/

1) you can use 'git merge -s ours', but you should only do that when you know you don't need the rest of the changes too.

2) You can also use git rerere, which helps resolve conflicts by memorizing what you did last time. You can enable its usage globally so it always "just works" by setting rerere.enabled. Or you can read the man page and do it by hand as well.

Wes Hardaker
  • 21,735
  • 2
  • 38
  • 69
  • rerere rocks. In fact, it rocks so much you frequently forget you're using it. – Wes Hardaker Aug 31 '12 at 16:31
  • 1
    Option 2) won't work if the version changes in anyway since git rerere recorded the merge conflict resolution. So not really an option IMO. – DarVar Mar 20 '17 at 12:18
2

You could also use a custom merge driver, as in pom-merge-driver. Depending on your workflow you might want to merge pom as a normal file, except treating the project version differently: always take the merging branch version, or make an exception when merging to the develop branch...

A.M.
  • 21
  • 1
1

Take a look at resolve-maven-version-conflicts.pl. It's a mergetool specifically to resolve pom conflicts. It'll ignore any change where both sides are -SNAPSHOT versions, but leave any other conflicts for further resolution.

Joe
  • 29,416
  • 12
  • 68
  • 88
1

I had the same problem and all solutions that i found didn't do it, imo, correct. Finally i wrote a merge driver which only takes care of the project/parent version and only them. No dependency version is changed nor the format of the xml file.

I released it a few minutes ago @ https://github.com/cecom/pomutils. If you have any questions, let me know.

Sven Oppermann
  • 321
  • 4
  • 9
  • 1
    The tool got now some more improvements. Now you can also auto resolve property values and it is possible to write your own conflict resolution rule. Have a look :-) – Sven Oppermann Jan 10 '15 at 07:01
1

In my case I have some future development to merge into develop:

  • example: some features in mybranch
  • mybranch version in pom.xml is: 3.11.0-SNAPSHOT
  • mybranch was forked before version 3.10.0-SNAPSHOT

To merge the new features into develop and force the pom.xml from the feature branch:

git checkout develop

  • develop version in pom.xml is still: 3.10.0-SNAPSHOT

    git merge mybranch

all pom.xml are in conflicts + eventually some other files.

Take all the pom.xml files (assuming nothing else than version has conflicts)

find -name pom.xml -not -path "**/target*" -exec git co --theirs {} +

I had to resolve some others conflicts like e.g. a deleted sub-project in my new branch before running the find command.

After that, all my pom.xml were in new version and compiling without any issue.

рüффп
  • 5,172
  • 34
  • 67
  • 113
0

Shouldn't it be as simple as wildcarding pom.xml since all of your versions are the same?

git checkout --ours *pom.xml
patrickjp93
  • 399
  • 4
  • 20