I’ve been using Gradle and Buildship for a while, but there is one thing that I have never completely understood:
Where is the line between the the functionality of Buildship and the functionality in the Gradle eclipe task?
For example: most of the time, importing a Gradle project into Eclipse works like a dream. That’s absolutely brilliant - Buildship makes me an Eclipse project that is perfect.
But I have some projects which generate source-code using Jaxb, so I might have a task called genJaxb.
The project will not compile unless Jaxb has created the classes and the output directory is a source folder, so I make the eclipse task depend on the genJaxb task.
Run ./gradlew cleanEclipse eclipse and the project is good to go.
When I clone that project from git and import it into Eclipse, the imported project has not executed the genJaxb task - I use the Gradle Tasks view to run the eclipse task and do a Gradle -> Refresh Gradle Project.
That seems a little counter intuitive - Buildship made me the Eclipse project, and now I’m telling the Gradle eclipse plugin to make me an Eclipse project too.
I have become accustomed to this - but colleagues are incandescent with rage for me making their lives so complicated…
I’m not trying to criticise - because Buildship is doing a brilliant job keeping me in Eclipse, helping me stay focussed and without need to switch to the command line. Most of the time Buildship does a brilliant job of making me an Eclipse project that mimics the Gradle configuration. I’m just wondering where the line is between it and the Gradle eclipse plugin.
Buildship does not use the gradle eclipse task at all. Instead, it talks to what we call the Tooling API. This API exposes the Eclipse model in a backwards and forwards compatible way. That’s why old Buildship versions work with new Gradle versions and vice versa. It allows us to implement things like the classpath container (making the .classpath file portable), which would not be possible when just calling gradle eclipse.
Some information is currently not exposed via the Tooling API and thus not available to Buildship. One of these things is “Which tasks do I need to run to to make this project work?”. This is on our agenda, but we have no concrete date for it yet.
You should not call the eclipse task from Buildship. This would overwrite Buildship’s configuration. Instead, just call the genJaxb task directly.
Thank you for the warm words and this important feedback. This helps us determine what the most important missing features are.
Thanks, Stefan. Sorry, I didn’t mean to imply that Buildship used the gradle eclipse task - but thanks for clarifying that.
I think I’ve inferred that the Tooling API you’ve spoken of is part of Gradle. So is it that buildship asks Gradle to load the build.gradle file and exposes the Tooling API which Buildship queries and does its stuff?
You said I should not execute the eclipse task, I’ll infer that I should also not execute the eclipse-wtp task. That really does make it quite hard for me to document for my colleagues how to import a web tools project.
Again, no criticism implied at all - I’m just here learning
Buildship does not support WTP at the moment. You will have to check in your component and facet xml files at the moment. Yet even with that, there is one more issue: Buildship currently does not mark the classpath entries as deployed/not deployed, so all jars are put into the war when you launch from Eclipse. This is something we are actively working on right now. Fully supporting WTP (creating the component and facet descriptors automatically) is on our agenda, but not yet scheduled.
No offense taken at all, thank you for the construtive feedback!
