I just tried with the new buildship version 1.0.1 to import the projects into a blank workspace. Before importing I deleted all existing Eclipse files “.project” and “.classpath”, so the import only sees the “build.gradle” files. The import run successfully, but Eclipse is not satifsfied and reports build problems.
These problems are due to the fact that we have a subproject, which serves as an Eclipse bundle, as a container for libraries used by subprojects in the form of an Eclipse plugin with a MANIFEST.MF describing all libraries and their exported packages. By this way, all other subprojects, which are Eclipse RCP plugins, depend on this project. This subproject itself has no java sources.
The buildship import process obivously does not recognize this, so Eclipse reports this problem:
Project ‘de.uvdms.ui.main’ is missing required Java project: ‘de.uvdms.root’ de.uvdms.ui.main Build path Build Path Problem
When I tried to add this missing project into the Eclipse “Java Build Path” of the complained project, I noticed there is a new org.eclipse.buildship.core.gradleclasspathcontainer visible in the “Libraries” tab, which lists all projects this projects depends on. But the project “de.uvdms.root” is not listed and I’m not able to add it.
The other thing I noticed: Buildship did not generate a “.classpath” file for this project (de.uvdms.root).
I hope, you understand the problem I tried to describe and can give me some tipps to solve my problem.
If I understand correctly you build Eclipse plug-ins with Gradle and you’d like to use Buildship to import them into Eclipse. Right now Buildship only support plain Java projects and has no understanding the OSGi-like dependency definition in the MANIFEST.MF.
The Gradle classpath container you see in the .classpath file is a container object which is populated with all the project and external dependencies defined in the build scripts. It should not be modified as it is populated from the Gradle model and can be refreshed at any time.
If you want to add a new workspace project or a library to the classpath, adjust the project build path as usual in Eclipse. Your changes will be stored in the .classpath file which Buildship will leave untouched.
Buildship by default creates general project instances in the workspace. Then, if there is at least one Java source folder is defined on the project, it gets converted to Java project. So probably your root project doesn’t have any Java sources. If it’s not the case, please let us know and we’ll investigate.
Yes, you’re right. This subproject does not have any java sources. It only has a MANIFEST.MF which declares to importing Eclipse projects what packages it offers. And it defines a lib directory, where the external jars are listed, which will be packaged into the jar. This is what Gradle build does. For the Eclipse view of dependencies, all these external libraries must be listed in the java build path.
And this is, what I expect if I do an import of this subproject with Buildship.
Look here how I did it in build.gradle:
configurations {
rootPluginConfig
rootPluginConfig.transitive=false
dllConfig
}
Sorry, donat. What I’ve shown you is an extract from build.gradle, which in effect works as excpected in our build.
But: importing the project with buildship is a quite different thing: that is generating .project and .classpath. I can do this at Gradle command line, and this works. What was generated by Gradle, was sufficient for the former Spring-IO Gradle plugin. But buildship does it different, and at this level, it doesn’t work.
Gradle’s Eclipse task obviously generates other output as does Buildship import task, following some new concept .
Just did another try importing this project into my Eclipse workspace. Now the import just of this project into a workspace, where all other Gradle / Buildship subprojects are already there, leads to an error with this stacktrace:
java.lang.IllegalStateException: Provided Eclipse project is not the root project.
at com.google.common.base.Preconditions.checkState(Preconditions.java:173)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultOmniEclipseGradleBuild.from(DefaultOmniEclipseGradleBuild.java:51)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultModelRepository$8.doForward(DefaultModelRepository.java:223)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultModelRepository$8.doForward(DefaultModelRepository.java:219)
at com.google.common.base.Converter.correctedDoForward(Converter.java:154)
at com.google.common.base.Converter.convert(Converter.java:147)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultModelRepository.executeAndWait(DefaultModelRepository.java:422)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultModelRepository.access$200(DefaultModelRepository.java:68)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultModelRepository$14.call(DefaultModelRepository.java:354)
at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4742)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2319)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2282)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2197)
at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4739)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultModelRepository.getFromCache(DefaultModelRepository.java:370)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultModelRepository.executeRequest(DefaultModelRepository.java:351)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultModelRepository.executeRequest(DefaultModelRepository.java:327)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultModelRepository.fetchEclipseGradleBuild(DefaultModelRepository.java:227)
at org.eclipse.buildship.core.projectimport.ProjectImportJob.fetchEclipseGradleBuild(ProjectImportJob.java:113)
at org.eclipse.buildship.core.projectimport.ProjectImportJob.runToolingApiJobInWorkspace(ProjectImportJob.java:92)
at org.eclipse.buildship.core.util.progress.ToolingApiWorkspaceJob$1.run(ToolingApiWorkspaceJob.java:74)
at org.eclipse.buildship.core.util.progress.ToolingApiInvoker.invoke(ToolingApiInvoker.java:54)
at org.eclipse.buildship.core.util.progress.ToolingApiWorkspaceJob.runInWorkspace(ToolingApiWorkspaceJob.java:71)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
If it wasn’t for a united, consistent concept and structure on the Eclipse everyday’s programer view and the Gradle build process view, I would not hesitate to have Gradle out from Eclipse. This “not-working”-situation nerves since more than one year, and is the biggest barrier for banning Jar dependencies from subversion/git and using Artifactory as the source for external dependencies.
Judging from the stack trace you’ve pasted I assume that you tried to import a project which is not a root project. Does it work if you start the import from the root project’s folder?
I’m sorry to hear raises some concerns of yours. Nonetheless if you have further issues the best way would be that you extract a simple example demonstrating the problem and attach it to this thread as a zip file. With that I will try to take a look.
to clarify: the cited project ‘de.uvdms.root’ is not in the root of a hierarchically organized project structure; it is a the same level as ALL subprojects. In the root of the workspace we have the gradle.build and libraries.gradle file, and of course settings.gradle.
The problems when importing the project ‘de.uvdms.root’ is this:
it does not generate a .classpath-file. Therefore Eclipse says:
Project ‘de.uvdms.bgetem.vm’ is missing required Java project: ‘de.uvdms.root’ de.uvdms.bgetem.vm Build path Build Path Problem
(… more of these …)
And the .project file is not correct, because important things for Eclipse are missing:
So please have a look into the files which I send you within the zip container.buildShip-Problems.zip (8.1 KB)
These demonstrate what Gradle itself produces when I call Gradle’s eclipse task; and you can see the difference to buildship.
Also note, there important builder-declarations missing in “.project”: javabuilder (although we have no java sources in this project), ManifestBuilder, SchemaBuilder.
did you have a look at my Zip? The thing here is so important for our Eclipse workspace, that the whole thing based on buildship produces nothing more than errors. It is because we have about 25 subprojects which all are based on our “root”-Plugin, because it is in this subproject where they can resolve foreign dependencies.
I’m waiting for 2 years now to be able to recommend my developer team to base the whole thing on Gradle projects; until now, we only have a buildserver using Gradle for release and nightly builds. So, there is still a gap between Eclipse and Gradle environments - which is a BAD thing.
as Donat mentioned in his first response: Buildship currently only generates correct .project/.classpath for plain Java projects. It does not handle Plugin projects correctly at the moment. You will have to check in your .classpath/.project files. Buildship will leave them untouched.