I am learning Gradle and have found my way around the normal use case. But now I have to step into integration with Eclipse (specifically STS) and need to learn more about how "Gradle projects" are imported into Eclipse (without having to generate the .project files using the inverse - Eclipse plugin for Gradle). By just attempting it I discovered that it did import my projects. However, projects written in Scala (some are pure Java, some Scala, some mixed) were not recognized and applied as Scala projects. In fact, Eclipse attempted to compile ".scala" files as if they were ".java" somehow and obviously failed miserably.
Tried Googling around to find more documentation on Eclipse integration but this appears to be significantly obscured by the "eclipse plugin" for Gradle in search results. Can someone, please, point me at documentation, if available, or provide at least some guidance with respect to my problem above...
Thanks!
I'm not sure what you mean by:
without having to generate the .project files using the inverse - Eclipse plugin for Gradle
Does this mean that you don't want to apply the Eclipse plugin in your Gradle project? Can I ask why? My experience of it has been very positive.
Here's what I've done in such cases:
apply the Eclipse plugin in my Gradle project (apply plugin: 'eclipse')
run the 'eclipse' Gradle task (gradle eclipse)
in Eclipse, do File>Import...>Existing projects into workspace and navigate to the Gradle project directory (or the root directory of a multi-project structure); (don't check Copy projects into workspace)
If the Gradle project also applies the Java plugin, you'll get a .project file that declares a javanature and refers to the javabuilder, and a .classpath file will also be generated. If not, you'll just get a vanilla .project file. The Gradle documentation makes it sound very much as if a similar thing applies in the case of the Scala plugin: http://www.gradle.org/docs/current/userguide/scala_plugin.html#N12EC0. Does this not work for you?
Related
Two Gradle Git projects need to be created, within the same repository, using the Eclipse IDE. Project A depends upon a third-party library (a JAR, source code, Javadoc and natives) and project B depends upon project A.
Without Gradle, both projects would be created and Git would be enabled with Project Explorer > [Project Name] > Team > Share Project. Then, dependencies would be added via Project Explorer > [Project Name] > Build Path > Configure Build Path, followed by Projects > Add and Libraries > Add External JARs (which would also allow the specification of the locations of related source code, Javadoc and natives). This would enable automatic code completion of Project A from Project B as well as source code and Javadoc integration, within Eclipse.
With Gradle, should the settings.gradle or build.gradle files be manually edited, without adding dependencies through the Eclipse GUI, or must both be used simultaneously? Additionally,how does this effect which hidden files should be indexed by Git (.project, .classpath, .settings, .gradle)?
How is this setup through Eclipse and Gradle?
When you use a build-tool like Gradle (or maven), it is kind of assumed that the build-tool is in charge of configuring stuff like project dependencies and classpaths.
This kind of conflicts with the Eclipse UI which is kind of built to allow you to manage classpath / dependencies via its own ui.
But the Eclipse UI only controls what eclipse uses as the classpath when the Eclipse JDT compiler compiles your code... inside Eclipse.
So if you change things that way, then Gradle will not know about these dependencies and the build won't work.
Yep, this is definitely confusing :-)
The proper thing to do is manage your dependencies and project configuration entirely through gradle. So that means editing the build.gradle and settings.gradle.
The tools (BuildShip or STS Gradle Tools) provide a 'bridge' to try and configure Eclipse projects in conformance with your build.
E.g they may offer a 'Update Project' or 'Refresh Dependencies' command in project context menu.
Even if you don't use Gradle tooling, this kind of holds true. You then would use Gradle's 'ecplise' plugin and run a command like
gradle cleanEclipse eclipse
To generate the eclipse project config from the build config. Then import the project into Eclipse as configured by gradle. Also in this case, it would be a bad idea to use Eclipse UI to make changes to the buildpath since ultimately it has the same issue, changes you make to those generated files may make things compile inside Eclipse, but Gradle doesn't know you changed anything. And the next time you run gradle cleanEclipse eclipse your changes are also blown away.
As to your specific questions:
should the settings.gradle or build.gradle files be manually edited ...
Yes.
... without adding dependencies through the Eclipse GUI ...
Yes.
... or must both be used simultaneously?
No, only configure things in gradle. Then 'synch it up' to eclipse with some tool (BuildShip / STS Gradle / gradle cleanEclipse eclipse)
How does this effect which hidden files should be indexed by Git (.project, .classpath, .settings, .gradle)?
General rule of thumb. Only index the stuff that defines gradle's behaviour (there may be some exceptions, but in general try to minimize them only violate this rule if you have a good reason).
So specifically don't put in git these 'eclipse metadata'
.settings
.project
.classpath
Do put in git: the gradle wrapper and its properties file.
Gradle also has a .gradle folder. It belongs to gradle, not eclipse, buts is caches and things which are 'transient'. You don't want those in git either.
Eclipse Mars was recently released and I felt like trying it out. It listed tighter integration with Gradle as one of its features via Buildship.
With Luna I was using Gradle Integration for Eclipse (4.4) and I found this a lot easier to work with for what I was trying to do; I could add a Gradle "nature" to an existing project without needing to remove the project and re-import it as I did with Buildship, and it automatically put all dependencies that I declared in build.gradle within the project's classpath.
With Buildship, I didn't see any option to configure an existing project as a Gradle project and I couldn't find a way to make it include the dependencies I specified in the build script within the project's classpath.
I tried installing the original plugin (GIfE 4.4) for Eclipse Mars and after restarting Eclipse it automatically did all that for me again. What I'm wondering is if there's a way to do this all through Buildship alone because right now, although it all works, it's quite a funny setup. My project's dropdown menu looks like this:
Apart from looking a bit odd it is actually quite a nice setup, since it combines the automatic dependency management of GIfE with the ability to run Gradle tasks directly from Eclipse that Buildship provides.
Updating the dependencies that eclipse sees should then be as simple as:
right click on project -> gradle -> refresh all
Update in buildship 1.0.16
Currently you need to jump through the delete-and-import hoop the first time you use an existing gradle project with buildship. You can now use the Add Gradle Nature option:
right click on project -> configure -> Add Gradle Nature
“Refresh Gradle Project” is now also shown when right-clicking on any .gradle file as well as in the context menu of the Gradle editor. source
See update below However sometimes you may find that when your project was imported, it didn't get the new Project and External Dependencies classpath entry which you would normally be able to see in your Project Properties -> Java Build Path -> Libraries
If this is indeed missing, add the following to your project's .classpath file and all the gradle goodness should start working:
<classpathentry exported="true" kind="con" path="org.eclipse.buildship.core.gradleclasspathcontainer"/>
Update in buildship 1.0.16
Gradle classpath container is restored if missing
When converting an existing Eclipse Java project to Gradle, the Gradle classpath container was missing. It is now always added when a project is a Java project.
Incase for anyone, if you are not getting the
right click on project -> gradle
link after doing the steps mentioned in #PaulAdamson answer. Try this.
In your build.gradle add apply plugin 'eclipse';
Close the project in eclispe.
Run the gradle build from command line and then reopen the project in eclipse.
Now the gradle link should be available on right click.
I agree Buildship is a bit of a disaster. The documentation is extremely sparse with limited examples and minimal user guide. You would think documenting the transition from Gradle Integration for Eclipse (4.4) would be a no-brainer but I guess not. I also don't have a single clue how to use Buildship other than that I ran some tasks manually and it put fully qualified paths in my .classpath file. That's ridiculous considering many projects are shared through change control systems.
Currently there is no "Convert to Gradle project" implemented in Buildship. However, if you remove the project and reimport it using the Gradle import wizard you should see the same exact project with the proper nature and the classpath container.
On top of that, if you have a Gradle project in your workspace and update the dependencies in the build script, you can refresh the classpath container by right-clicking on the project and select Gradle > Refresh projects.
A similar problem you were facing was discussed in the Gradle forums: discuss.gradle.org/t/adding-dependencies-to-projects/10415.
We also have a bug dedicated for this feature request: bugs.eclipse.org/bugs/show_bug.cgi?id=465355. Please vote for it and share your thoughts there too.
Regarding to the documentation: It's true that we haven't provided an official documentation for the central Eclipse help system, but there are some resources explaining the current functionality:
The user documentation on GitHub
A Vogella tutorial
If you have already converted Java project to Gradle project but [RIGHT-CLICK]+Import (Then importing 'Existing Gradle Project') then your project should be of Gradle Nature.
If the project is of Gradle Nature then in .classpath file you will not see all the .jar dependencies as you see in normal java project, Instead you will see a single entry of:
<classpathentry kind="con" path="org.eclipse.buildship.core.gradleclasspathcontainer"/>
To refresh dependencies you should do following:
[RIGHT-CLICK] + Gradle + Refresh Gradle Project
This will fix all complication issues.
I am trying to achieve the following between Eclipse and Gradle:
Allow Gradle to handle 100% of my local build logic; only use Eclipse as an IDE for syntax highlighting, refactoring, etc. Every time I wish to build my app I want to drop into a command line and run a Gradle build invocation from there.
I want the dependencies closure of my build.gradle file to be the sole location for configuring 3rd party dependencies; every time I make a change to this closure (adding/removing a dependency/JAR), I want Eclipse to automagically "see" this change and adjust my project's classpath accordingly
I installed the Gradle-Eclipse Integration plugin and then I followed this tutorial for configuring it correctly.
First I ran:
gradle clean build
And then I added:
apply plugin: 'eclipse'
To my build.gradle, and then ran:
gradle eclipse
I saw a lot of output, the tail end of which is:
gradle eclipse
:myapp:eclipseClasspath
Download http://repo1.maven.org/maven2/org/apache/commons/commons-lang3/3.3.2/commons-lang3-3.3.2-sources.jar
Download http://repo1.maven.org/maven2/org/sonatype/sisu/inject/cglib/2.2.1-v20090111/cglib-2.2.1-v20090111-sources.jar
Download http://repo1.maven.org/maven2/asm/asm/3.1/asm-3.1-sources.jar
Download http://repo1.maven.org/maven2/com/google/inject/guice/3.0/guice-3.0-sources.jar
Download http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.3.7/groovy-all-2.3.7-sources.jar
Download http://repo1.maven.org/maven2/aopalliance/aopalliance/1.0/aopalliance-1.0-sources.jar
Download http://repo1.maven.org/maven2/javax/inject/javax.inject/1/javax.inject-1-sources.jar
:myapp:eclipseJdt
:myapp:eclipseProject
:myapp:eclipse
I then opened my .classpath file and see that its been correctly updated with all the transitive dependencies defined in my dependencies closure back inside build.gradle.
However, there is not visual indication inside Eclipse that anything is wired correctly. With Ivy or Maven, you usally get something like a Ivy Repository Manager or Maven Dependency Library that automatically changes anytime you modify ivy.xml or pom.xml.
Most importantly, this just doesn't seem to be working! As you see above, Apache Commons Lang 3 is a dependency, but when I try to add org.apache.commons.lang3.exception.ExceptionUtils to a Groovy source file, Eclipse can't find it. I have already tried restarting Eclipse to see if that shook any bugs out.
Am I just not using this plugin correctly, or does it just not work? Using Groovy/Grails Tool Suite 3.6.0.RELEASE here, which is based on Eclipse Luna 4.4.
My eclim setup working perfectly with eclipse project. But I want to use gradle build system.
I am working with Libgdx framework and it provide gradle templete project.
So is there any way to use eclime + eclipse + gradle
Your best bet is to check out the Eclipse Gradle plugin, although in short you can add apply plugin: 'eclipse' to your project and then run gradle eclipse from your terminal in the root folder of your project. That should generate the necessary files for Eclipse to recognize your project, although you might need to edit the .classpath file for proper autocompletions.
That will get Eclim to recognize your project with :ProjectOpen and proper autocompletion and other goodness.
The bad is that Gradle tasks and changes to your build.gradle will require manual changes to the Eclipse side of things.
Edit: There's a new plugin available for this purpose that replaces eclim for gradle projects (but is android oriented) called Vim-Grand. It's pre-alpha and you'll want the refactor branch for now, but it's working well enough for me
You should combine it with YouCompleteMe.
What I did was use the gdx-setup.jar to create my project. I then imported it into eclipse like a normal gradle project. I closed eclipse and started up elcimd. Put "let g:EclimCompletionMethod = 'omnifunc'" in my .vimrc file. Followed the elcim instructions to use :CreateProject and that was it.
This guide was really helpful: http://www.lucianofiandesio.com/vim-configuration-for-happy-java-coding
I am able to get most or all Eclim functionality working with my libgdx project this way:
create a new libgdx project with their tools
start Eclipse
Import --> Gradle Project --> Build Model per usual libgdx project creation
shut off Eclipse, start Eclim
I get organize imports, java validation, autocompletion, all the good stuff.
That said, I want to figure out how to do this all without having to use Eclipse. I think the missing piece is the Build Models functionality. Still researching ...
I have a list of Eclipse projects that I would like to compile based on the existing project configuration.
As far as I can tell, if an ant script could read the .classpath files, it would pretty much be able to infer the project dependencies and perform a "javac" compilation in the right order. This would save time in describing the same dependencies again in the ant script or a Makefile.
The dependencies I am interested in are JAR Dependencies, JRE dependencies, and inter-project dependencies. These are -- as far as I can tell -- part of the .classpath XML file.
Any ideas on how Eclipse project dependencies could used in an ant script?
Right click on your Project -> Export
"General/Ant Buildfiles".
Choose the projects and there you go.
Otherwise...
I have some experience with ant4eclipse and it is a hassle to get it stable.
Go check Buckminster or Maven Tycho for a good solution.
I'm currently using Ivy along with Ant, Eclipse and Maven.
I just love the way Ivy works.
Currently, we have a workspace with many projects using Liferay (with Tomcat) for the front-end and Glassfish for the back-end.
We were looking for a way to manage our dependencies a lot better than how we were doing it.
So I took Ivy, replaced all of the classpaths and deployment dependencies in eclipse and was able to build my application using 1 ivy file per project using either Eclipse or Ant.
Ivy integrates like a charm in ant and builds are done either from the workspace or by command line.
I strongly suggest you look at this avenue. Additionnaly, by adding Artifactory, we have a local repository in which the ivy files look for dependencies. This helps us maintain and rule which jars are to be used by developpers. Once everything is setup, we will build our application nightly using Jenkins and these builds will be using our Artifactory repository to resolve dependencies since our build servers do not have access to the internet.
Hope this helped
If you are running the Ant script only from eclipse using the "External Tools Configurations", you can add the variable ${project_classpath} to the Classpath.
Depending on if you are in a plugin project and dependencies you might need to add the
${eclipse_home}.
In case you get an error launching Variable references empty selection: ${project_classpath}, make sure the ant xml file or at least the project is selected. This is important.
I believe the ant4eclipse project provides support for executing Ant builds based on Eclipse metadata files.
However, in my opinion that is doing things back to front. You shouldn't have your build (Ant) depending on your IDE (Eclipse) environment. But it is useful if you can derive your Eclipse environment from your Ant build.
This is an approach used successfully in a team I worked in. We had a helper Ant target which applied XLST to project build.xml files to transform these into Eclipse .classpath files. Thus the Ant build.xml files were the single configuration point for our projects.