I’m having some trouble in understanding how buildship and eclipse work together.
I usually enable automatic build in eclipse.
I would like to understand better what is the interaction between the two tools, how the integration takes place.
Is it good to have the automatic build of eclipse or is it better to launch the build from the Gradle task view?
What is the difference between running the Gradle build via the command line?
Eclipse builds classes in the bin folder while Gradle builds by default in the build folder. How is this behavior with buildship?
Do you have any advice on how to best use buildship with a multi-project of large dimensions in order not to impact the performance of eclipse?
Yes, you can keep automatic building enabled in Eclipse. Eclipse compiler (JDT) will compile classes in bin folder, as usual, while Gradle (driven by Buildship) will build artifacts in the build directory, but only when you explicitly run a Gradle task in the build group, either via command line or via the Gradle Task View in Eclipse. But you normally do not need to do that while developing and running your application within the IDE, as you usually would run it using Launch Configurations as you normally would do.
The real role of Buildship is to set up your Eclipse project so that its configuration is as much as possible adherent to what build.gradle says, so it will, among other things:
create Eclipse projects corresponding to your Gradle projects (i.e.: one for each subproject + the master project in a Gradle multiproject)
enable the necessary project natures for each project depending on the plugins you apply in build.gradle (i.e. Java nature when java or java-library plugins are applied, Groovy nature with the Groovy Eclipse plugin when the groovy plugin is applied, Kotlin nature when the kotlin plugin is applied, WTP Dynamic Web Project when war and eclipse-wtp plugins are applied, and so on)
adjust project build path by applying the right JRE and a classpath container containing all the dependencies as computed by Gradle given your declarations in build.gradle (and downloaded signally l automatically from the Maven repository)
adjust the runtime class path when you create launch configurations
… and so on.
In this way, starting your application within the IDE (with Eclipse facilities) should produce a result as much as possible equivalent to what you get it you build your project with Gradle and then start it
During development, Buildship will then run Gradle only when you change something in build.gradle and/or when you do a right click → Gradle → Refresh Gradle Project on the Eclipse project. And it’s usually quite fast.
I’m currently trying to figure out why my Eclipse takes a lot of time doing Gradle refresh and building projects. I have a multiproject with abut 1000 sub projects and the whole IDE is not so fast saving and compiling java files.
I know that Intellij and Netbeans use Gradle directly to build the projects, I’ve done some test with them, but what about Eclipse and Buildship?
Well I created a simple multiproject with 2 subprojects. I executed ‘build’ task via Gradle task view and both bin and build folder are created and both of them have class files inside.
So execute tasks from gradle task view is not so fast and productive. As you said automatic build works is a good choise, but still I don’t know why Gradle refresh takes so much time but maybe this is something to discuss in anothe topic.
Because Gradle task executed via Buildship does not reuse the compilation done by Eclipse, they cannot benefit from eachother compilations. At the end I have 2 compilation for the same files using Eclipse and then running a Gradle build task via command line…
As I said, Eclipse is NOT using the Gradle build to provide its features (compiling, error reporting, syntax highlighting, run through Launch Configurations, etc.). It’s the standard JDT compiler that is kicking in whenever you save a file and “Build automatically” is enabled. Gradle is not doing anything there.
Gradle only intervenes when you do a “Refresh Gradle Project”, which however you need to invoke only when something in your build files change (or, by experience, when the Gradle cache has expired and you need to refresh your dependencies… this happens when you don’t use a project for months).
So, yes, there’s a duplication (which however it has its pros, IMHO, and is justified by the fact that Eclipse uses its own compiler, JDT), but from a performance point-of-view this should not be a huge problem, unless you need to build your Gradle project from the command line very often for whatever reason. But also in that case, since Gradle caches its outputs, you only pay the whole bill on the first Gradle invocation, subsequent ones should be relatively fast anyway.
So why Eclipse is slow at saving files in your case? Honestly I don’t know, perhaps 1.000 subprojects are indeed a lot of projects and interdependencies between them may create some long paths that stress JDT on your system, but I’m just guessing.
