Eclipse import fails


(Markus Oley) #1

Gradle Version: 2.13
Eclipse version: Mars 4.5.2,
Buildship version: 1.0.21.v20161010-1640
Operating System and JVM version: MacOsX 10.11.6 with jdk 1.8.0_73
Is this a regression? Yes, I think I can remember that this works with 1.0.16 - but not sure

On a multi-project-build:

include 'project/module1'
include 'project/module2' 


allprojects {
  apply {
   plugin 'java'

project(':project/module2') {
  dependencies {
    compile(project(':project/module1')) {
      transitive = false

I get an exception when importing the project into eclipse :

Path for project must have only one segment.
java.lang.IllegalArgumentException: Path for project must have only one segment.
    at org.eclipse.core.runtime.Assert.isLegal(
    at org.eclipse.core.internal.resources.WorkspaceRoot.getProject(
    at org.eclipse.buildship.core.workspace.internal.DefaultWorkspaceOperations.createProject(
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.addNewEclipseProjectToWorkspace(
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeNonWorkspaceProject(
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeGradleProjectWithWorkspaceProject(
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeGradleBuildWithWorkspace(
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.access$000(
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation$
    at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.synchronizeBuild(
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.runToolingApiJob(
    at org.eclipse.buildship.core.util.progress.ToolingApiJob$
    at org.eclipse.buildship.core.util.progress.ToolingApiInvoker.invoke(

We need this structure ‘project/module’ because the artifacts are located in artifactory this way and we want to handle multimodules were a local module can overwrite an version from server

One hint: On commandline and with IDEA our structure works as expected.

Can you please give me advice how to handle or fix this bug in buildship?

(Stefan Oehme) #2

Project paths are logical paths separated by :, not /. It should be project:module1

(Benjamin Muschko) #3

If I am not mistaken, then the character / in a project path isn’t really “supported” by Eclipse. I believe we are planning to disallow this character in a future version of Gradle to avoid issues. Any chance you can use camel case notation? For reference please see issue 751.

(Markus Oley) #4

Hi Stefan and Benjamin,

thank you for your replies.
We have the problem, that our projects are located in artifactory as project/module. I work in a department, which provides tooling for the developers of our projects. So I shall provide tooling for a given structure :frowning:
And our structure in artifactory is this hierarchical one, where the name is a complex name named project/module. So we tried to map our multimodule project the same way in the filesystem, which works for commandline and idea. We have to find a way, that it also works for eclipse. Can you please give me a hint, how we can refactor our structure that it will work, perhaps to be a bit more like the default?

The problem with it is that gradle does not notice that a project named :project:module is the same as a dependency ‘’ and does not replace the dependency with the correct project dependency from multiproject.

Do we have to refactor it the following:, name=modulename
or is there a possibility to get it working with less impact?


(Stefan Oehme) #5

I strongly encourage you to refactor this. Putting / in project names will almost certainly be an error in future Gradle versions.

Until you’ve fixed those names you can work around it by explicitly setting to something else.

(Markus Oley) #6

Hi Stefan,

thanks a lot, the workaround is working and we will refactor the artifact to a simple one and add the project to the group in middle-term