Evaluating moving from Eclipse & Ant builder-based setup to Gradle/Buildship -- is Build Automatically possible?


(Michael Hyde) #1

Hello, pretty new to Gradle, and looking at the possibilities of improving a legacy Ant-based build with the kinds of benefits that Gradle can bring, esp. with regards to dependency management which has been manually managed to date.

It’s a multi-project build that’s often handled as a broad checkout of a number of projects comprising common libraries, utilties and testing frameworks, and multiple webapps, to enable both unit and integration testing in one’s local Eclipse workspace.

Developers use Eclipse with Build Automatically turned on, with Ant builders set up to generate jar files, and number of Ant run configurations to perform various tasks to support the build/test/repeat cycle.

With Gradle and Buildship, I’ve managed to construct a working subset of the overall system, by having each project produce a jar, and publish to mavenLocal, and handling inter-project dependencies via respective jar files, i.e. as binary- instead of project-based dependencies.

Supposing this approach is okay, I’m confused how the Eclipse developer experience with Buildship is supposed to work, in the absence of any kind of Build Automatically support, or the ability to define a “Gradle Builder” much in the same way an Ant Builder could be constructed.

E.g. if I run an Eclipse “clean” on a project or all projects, that doesn’t imply that a Gradle “clean” is executed, along with proper post-clean refresh of the workspace. Nor does a “build” operation via Eclipse’s project menu have any implicit connection with a Gradle project’s build task.

Instead I have to manually run builds on projects, remember to publish when i make a change, etc. I’m sure there’s a better way (perhaps with multi-project and/or composite builds?) but can such items be automatically triggered from traditional Eclipse operations?

Is there any kind of cheat sheet or list of caveats that describes what features, expectations, or operational behaviors that traditional Eclipse users lose and/or should modify when moving to a Gradle-build approach with Buildship?

I do appreciate the enhancement in Buildship 2.2 that makes it possible to automatically reload build.gradle file after changes. That’s a big help.

The competing alternative here is to move to Maven & Tycho approach that’s shown a bit more promise with regards to integrating into traditional Eclipse builder operations.

Hope these questions/concerns make sense – I’m very new to Gradle and appreciate any and all insights and feedback. THANK YOU!

P.S. I see that this issue is very similar. So in the absence of this, what do people do in Eclipse to not have to “mentally keep track” of what to manually execute in Gradle, after making code changes and saving?


(Stefan Oehme) #2

That doesn’t sound like the right approach. If it’s a multi-project build, it should be project dependencies. The publishing in between just means a lot of wasted time. It also means they won’t be set up with the appropriate Eclipse project dependencies when importing with Buildship.

It hasn’t been heavily requested so far, so every voice counts. I guess a lot of users are happy with the basics (i.e. Eclipse compiling Java code and running tests via Gradle).