Why do subprojects in my multi-part project appear in Eclipse as top-level projects?


(bobpaige) #1

(Please consider that I am very new to Gradle, though have been using Java/Eclipse for many years)

We are just converting from CVS/Ant to SVN/Gradle.

With CVS/Ant, when a given project had many artifacts to produce, we just added extra targets to the build.xml file.

Looking at Gradle, I’m thinking the preferred method would be to decompose the project to subcomponents each with their own build.gradle file. Fine so far.

But when I create a sample multi-project it creates multiple top-level projects that result in name collisions.

For example, using the Gradle IDE plugin for Ecilpse, creating a sample multi-project results in the following file structure:

test 1/
  build/
  build.gradle
  my-lib/
  product/
  settings.gradle

with some HelloWorld stuff in the source directories.

In Eclipse, this appears as THREE projects: - test1 - my-lib - product

This is a big issue.

When I’m working on a project, I like to check out multiple copies as I’m usually working on multiple tasks within the same codebase. This behavior of Gradle (or the GradleIDE plugin) actively prevents me from doing so.

For example, if I try to create another project ‘test2’ using the same multi-project template within Eclipse, it fails because both have ‘my-lib’ and ‘product’ subprojects.

Does anyone know a better way to handle this in Eclipse?


(Bryan Helm) #2

Sorry there is no answer here as this is the only search result for “eclipse CVS multi-project gradle build”. My symptom is different but perhaps related. My top level project thinks the files on the disk are different than the files in CVS. Eclipse Team Synchronizing reports all files as incoming files, but update fails with ‘a resource already exists on disk’. Everything is up to date on disk according to CVS. Rebuilding everything from scratch does not help.


(bobpaige) #3

Yours sounds like a typical CVS issue (http://journal.missiondata.com/post/63401404083/cvs-update-move-away-foo-bar-it-is-in-the-way).

Our final solution was to not use the Eclipse Gradle plugin as we commonly have multiple copies of the same project (or related projects) checked out into a given workspace.

If you choose to continue in this direction, one other recommendation I found was to create a separate Eclipse workspace for each project. We did not go in this direction as I felt it was overkill. Kindof like saying “if you need two sinks in your house, create a second house.”


(Bryan Helm) #4

Not typical in that the files are all present in CVS/Entries so I don’t know why it is complaining. Not a naming issue, the names are all identical. It seems it knows the file is in the sub-project, but somehow thinks the parent directory makes the same file a different file. I thought it was an eclipse issue until I got a bunch of move file away messages from TortoiseCVS.

I hate it when the answer is don’t use that.


(bobpaige) #5

And that is why we are migrating to SVN. We struggled with the ‘move away your files’ bug in CVS for years.


(Bryan Helm) #6

I’m trying to get us to Git…