[GRADLE-443] Generated POM dependencies do not respect custom artifactIds Created: 13/Apr/09  Updated: 04/Jan/13  Resolved: 10/Jul/12

Status: Resolved
Project: Gradle
Affects Version/s: 0.5.2
Fix Version/s: 1.1-rc-1

Type: Bug
Reporter: Paul Speed Assignee: Peter Niederwieser
Resolution: Fixed Votes: 6

Issue Links:
Duplicate
Duplicated by GRADLE-1238 POM generated by Maven plugin include... Resolved
Related
Related to GRADLE-798 Allow for full customization of the p... Resolved

 Description   

Using the maven plug-in, project poms can be generated with custom artifact IDs by changing the pom.artifactId. The problem is if this project is included as a dependency of another pom, then the custom artifact ID is ignored and the default project name (the directory) is used instead.

An example...
Let's use the following directory structure:

myproject
settings.gradle
/foo
build.gradle
/bar
build.gradle

Now, let's say that "bar" depends on "foo". Now let's also say that I've modified the pom.artifactId in both projects to be "myproject-foo" and "myproject-bar" respectively.

foo's pom.xml gets generated with artifactId "myproject-foo". Good.

bar's pom.xml gets generated with artifactId "myproject-bar". Also good.

The problem is that the "foo" dependency in "bar" is using artifactId "foo"... and so maven users trying to use "bar" will never find it.

<dependency>
<groupId>mygroup</groupId>
<artifactId>foo</artifactId>
<version>1.0</version>
</dependency>



 Comments   
Comment by Hans Dockter [ 10/May/09 ]

I postpone this issue to 0.7. It is not trivial to solve as every upload task has the freedom to customize the uploaded pom (and we had use cases where this was done in multiple ways). What we want to provide in 0.7 are dynamic properties for dependencies. That way you will be able to specify the maven artifactId as part of the project dependency.

Comment by Paul Speed [ 11/May/09 ]

At least there is a work-around: rename the projects to something other than their directory names...

From an outsider's perspective, it seemed like since gradle had all of the projects loaded that it would be able to know what the other projects had set their maven project ID to be in the "maven-installer"... since that would be pretty specific to other maven installers. Sounds like it is not so straight-forward (unfortunate, I guess).

So are you saying that in the future there might be some kind of consistent maven POM model for a project to customize? Ah, or is every one of my sub-projects now going to have to refer to each other by both gradle name and maven name?

If so... I think like renaming the projects better.

Comment by Hans Dockter [ 12/May/09 ]

We want to make your life easy not harder. So let's see what we can come up with. Once I start working on this issue, I will discuss the strategies for implementation in this issue (or on the dev list).

The thing is that there might be a 1-1 relationship between project and artifacts. But this is not necessarily the case. In Gradle a project can have as many artifacts as it wants to have. A project dependency can also only pick a subset of the project artifacts. There are quite a few degrees of freedom here. On the other hand we should make life simple for maven-like projects. I'm sure we will be able to work something out that support all the use-cases well.

Comment by Hans Dockter [ 22/Apr/10 ]

We will make this more convenient in 1.0. Therefore I leave this issue open. But there is a new option in 0.9 how you can solve this problem. You can manipulate the generated pom. You can say:

uploadArchives {
    repositories.mavenDeployer {
        // In the future Gradle will allow to use dynamic props for dependencies to deal with optionals
        pom.whenConfigured {pom ->
            // dep is a native Maven dependency object (With properties artifactId, groupId, ...)
            pom.dependencies.find { dep -> dep.artifactId == 'bar' }.artifactId = 'myproject-bar'
        }
    }
}

In 1.0 you won't need to say the same thing twice.

Comment by Chris Beams [ 29/Jul/10 ]

This issue affected the spring-amqp project gradle build prototype. It has a subproject directory named spring-amqp-core, where the actual artifact baseName needs to be just spring-amqp. In maven this was done simply by changing the <artifactId/> in spring-amqp-core/pom.xml. Ideally in gradle we would have needed only to say

jar {
    baseName = 'spring-amqp'
}

but because of this issue we cannot. The workaround then, was to make the following change:

cbeams@anakata:~/Work/spring-amqp[gradle]>$ git diff settings.gradle 
diff --git a/settings.gradle b/settings.gradle
index 8998cdd..c9876dc 100644
--- a/settings.gradle
+++ b/settings.gradle
@@ -20,9 +20,12 @@
 include 'docs',
-        'spring-amqp-core',
+        'spring-amqp',
         'spring-erlang',
         'spring-rabbit',
         'spring-rabbit-admin',
         'spring-amqp-samples:helloworld',
         'spring-amqp-samples:stocks'
+
+project(':spring-amqp').projectDir = new File(settingsDir, 'spring-amqp-core')

And, of course update all other .gradle files to refer to :spring-amqp instead of :spring-amqp-core

Comment by Peter Niederwieser [ 10/Jul/12 ]

Changes to project.archivesBaseName are now automatically reflected in the referencing project's POM. If a project changes archiveTask.baseName, make sure to change uploadTask.repositories.mavenDeployer.pom.artifactId along with it, which will again be reflected in the referencing project's POM.

Once the new 'publication' concept comes along, we'll be in a much better situation to handle this and similar cases in a simpler and more effective way.

Generated at Wed Jun 30 11:30:15 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.