Eclipse buildship create source & test working sets


(Marc Pawlowsky) #1

Is there a way in the build.gradle files to specify that in Eclipse I want the src/main/java files to go into a working set, and src/test/java to go into another working set?

My use case is that I have may sub-projects, that have production and unit test code.
I often want to see the references to a class in the production code, but not the test code.
Creating a working set manually is painful due to the large number of projects.


(Donát Csikós) #2

The short answer is no: there is no configuration option in Gradle core nor in Buildship at the moment. One reason why it was not considered because Buildship and Gradle has a focus on the project configuration only and don’t do much in terms of the workspace configuration. Still, it would be interesting to see how it could be modelled in the build script.

My main concern about this feature is its obscurity: not many people know that you can add any elements to a working set, not just a projects. So if a build user would import a project using this feature would immediately ask us “Where did my test classes go, why do I see only my production classes?”.


(Marc Pawlowsky) #3

I am not sure I understand your concern.

What I am thinking of is the import would have the same behaviour as currently, with production and test under the project.

The new functionality would be so I could right click on a method, choose References/Working Set …, and a working set that I had defined in the build.gradle would be available. It would be a way of specifying not just Eclipse project features, but also something that belongs to the Eclipse workspace.


(Donát Csikós) #4

Buildship is implemented with the ‘build script is single source of truth’ principle in mind. Consequently, if we implemented this feature it would look like this:

  1. the Eclipse DSL is extended to define working sets along with their contents
  2. Buildship would pick up the DSL configuration and update the working sets upon project synchronisation

The implementation is a bit more complex, than it looks like: we should introduce new DSL elements, then expose them via Gradle’s tooling interface, and finally make use of the new information in Buildship. Although it’s not hard, it still it takes considerable amount of development time, where the amount of people benefiting from this feature is not evident.

Nonetheless, if you are interested in implementing it, both Gradle and Buildship are open for pull requests.


(Stefan Oehme) #5

The problem with specifying workspace configuration in a build is that the workspace can contain many different builds. What if two builds have workspace configuration that conflicts with each other? Also it can quickly result in “spooky action at a distance”, i.e. you import a project and suddenly your workspace settings change.