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.

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.

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.

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.

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

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.