uploadArchives creates incorrect pom.xml on jdk8?

(Kristian Rosenvold) #1

We have a project where running “uploadArchives” with jdk7 generates a pom with class path elements in one order. Switching to jdk8 emits a pom with elements in a different order. According to my understanding of maven, the pom elements should never have random order; is this a known problem ?

(Kristian Rosenvold) #2

I’m not sure I understand this;

org.gradle.api.publication.maven.internal.ant.DefaultPomDependenciesConverter#convert seems to produce a “List” of dependencies largely by iterating hash maps. Am I missing something ???

(Peter Niederwieser) #3

Please post a concrete POM snippet showing the differences. If you are talking about order of ‘dependency’ elements, the order is irrelevant.

(Kristian Rosenvold) #4

No, you are wrong about this, pom.xml order also defines class path order, and ordering may be important, in particular for resource loading. This was fixed in http://jira.codehaus.org/browse/MNG-1412 and http://jira.codehaus.org/browse/MNG-3111 and has been this way since maven 2.0.9.

The gradle code I found matches your misunderstanding of how pom.xml works, and there is no point in posting any kind of sample for this.

(Peter Niederwieser) #5

I was asking for a sample to clarify what you mean by “generates a pom with class path elements in one order”. (Dependency declarations aren’t class path elements.) Thanks for pointing out http://jira.codehaus.org/browse/MNG-3111. Perhaps we should switch to ordered collections. Would you be interested in contributing such a change?

(Kristian Rosenvold) #6

Originally I bumped into this because we were trying to find out why our build was failing. We discovered the mutating pom.xml file because we were deploying with jdk7/8 while trying to identify our primary problem; it would appear that hash map iteration order is (once again) different in jdk8 - which caused large variations in as-deployed pom.xml files. Since I am intimately familiar with the maven pom parsing logic, I thought I would raise this issue.

Now it would appear the root cause of our problem is a different bug, which is actually far more evil. We’re still working on zooming in on that problem. I think we’ll try to fix that problem first…

(Peter Niederwieser) #7

Raised as GRADLE-3004.