[GRADLE-3030] Classifier missing in generated pom.xml based on project dependencies Created: 21/Feb/14  Updated: 26/Apr/16  Resolved: 26/Apr/16

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 2.14-rc-1

Type: Bug
Reporter: Gradle Forums Assignee: Pepper Lebeck-Jobe
Resolution: Fixed Votes: 4

Attachments: Java Source File DefaultPomDependenciesConverter.java     Text File TestCase.txt    

 Description   

Hello fellows,

I commented in netmikey's post [[1]http://forums.gradle.org/gradle/topic...] the other day about Maven dependencies in Gradle 1.9+ not working entirely satisfactory.

See the examples in the other post.

Having further investigated the problem from what I can see my issue boils down to the generated pom.xml not correctly containing the classifier when generating the pom.xml file based on project dependencies. When generating a pom any classifier specified as external module dependencies translates into the pom, for project dependencies it does not.

I dont think it ever has for project dependencies, but Gradle 1.8- made it work anyway. Now with the stricter/correct pom interpretation it does not work.

External dependencies block and pom.xml:

dependencies {
compile 'deptest.B:B:1.0'
testCompile 'deptest.B:B:1.0:test'
}

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>deptest.D</groupId>
<artifactId>C</artifactId>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>deptest.B</groupId>
<artifactId>B</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>deptest.B</groupId>
<artifactId>B</artifactId>
<version>1.0</version>
<classifier>test</classifier>
<scope>test</scope>
</dependency>
</dependencies>
</project>

Project dependencies block and pom.xml:

dependencies {
compile project(":A")
testCompile project(path: ":A", configuration: 'testRuntime')
}

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>deptest.B</groupId>
<artifactId>B</artifactId>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>deptest.A</groupId>
<artifactId>A</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>deptest.A</groupId>
<artifactId>A</artifactId>
<version>1.0</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>

No classifier on the test scope even though it is specified on the test-jar.

In the testRuntime configuration I have placed a test-artifact for test-dependencies used as above. The classifier linked to this artifact however does not translate into the pom which cause the latest entry in pom per artifact priority issue.

Thank you,
Stefan
----------------------------------------------------------------------------------------
[1] http://forums.gradle.org/gradle/topics/gradle_1_9_dependency_resolution_issue_if_artifact_present_in_multiple_scopes_within_the_pom

 Comments   
Comment by Gradle Forums [ 21/Feb/14 ]

Hello,

Usually you are pretty fast to respond on a query with at least a yes/no/maybe.

If my report is unclear I can supply more examples.

When writing the pom.xml the classifier specified (if one is specified) on the artifact is not written into the pom through project dependencies. My test-dependency above become a classifier-less (normal) dependency on the test scope when it should also have had 'test' as classifier as specified on the jar-task.

Thanks,
Stefan

Comment by Stefan Marklund [ 27/Mar/14 ]

Suggested patch of converter class and simple test.

Comment by Stefan Marklund [ 27/Mar/14 ]

Hi Gradle devs,

After taking some heat internally about the poms we are publishing I figured that the best way to speed up the resolution of this jira was to try and make a fix myself.

I believe I have a solution that writes correct poms.

DefaultPomDependenciesConverter.createMavenDependency gets a null classifier into the function. In the event of a ProjectDependency in addition to the artifactId the classifier is looked up from the artifact to publish.

Feel free to tidy up the solution.

I would much appreciate if someone had a look and closed out this jira.

Thank you,
Stefan Marklund

Comment by Noam Asor [ 23/Mar/15 ]

This issue affects also gradle 2.X branch it seems.

I have set classsifier property on default jar task, and then used the task through publication from() method to generate default jar artifact with classifier. Until here everything went fine. But when inside a multi module project, and another module is dependent on the above module. The generated pom for the dependent module is not adding the classifier in the dependency list, hence a project that uses this dependent module fails to compile as there is no module in the repository without the classifier.

I will be happy to supply any other details regarding that if needed.

Regards,
Noam

Comment by Ray [ 03/Aug/15 ]

It seems like another solution might be to update DefaultProjectDependency to override getArtifacts() and return the artifacts from its ProjectConfiguration. That seems a bit more straight forward, but I'm not clear on what the side effects of a change like that would be.

Is there any way to tell if a solution to this is on the horizon? We currently publish a large number of test jars in a large multi-module project that I'm working to enable running through a parallel build pipeline. This issue is preventing my integration tests from compiling because I use an external reference for the current project (which has a classifier) and so it cannot properly understand the dependencies. I'd submit a patch with the above change if that would help this to move any faster, but since the above suggestion is over a year old, I wonder if there's another impediment to fixing this.

Thanks,
ray

Comment by Ray [ 24/Aug/15 ]

Pull request for this fix logged here: https://github.com/gradle/gradle/pull/504

Generated at Wed Jun 30 12:38:00 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.