Letting included builds be controlled by the project's open/closed status

Help/Discuss Buildship
1

I’m currently planning to migrate all our projects from Gradle (STS) plugin to Buildship.
There is a special functionality in Gradle (STS) plugin what I’m still not sure how to realize it with Buildship. Therefore this post here.

I have a bunch of projects which are partly and irregularly depending on each other (w/o cycles).
I would like to arrange them in a composite build to get advantages from Buildship to substitute binary library dependencies (jars) by project dependencies if the particular project is checked out to Eclipse.

This is already working today by setting up a “parent” project referencing all potential projects inside its settings.gradle file similar to the following:
if (file(’…/project-client’).exists()) includeBuild ‘…/project-client’
if (file(’…/project-server’).exists()) includeBuild ‘…/project-server’

In that case Buildship substitutes a binary dependency if the particular project has been checked out and substitutes it back if the projects gets deleted from the Eclipse workspace.

As this works well, deleting a particular project from Eclipse is not the common case. Instead we close (means, by the Eclipse Close menu entry) a project to get it invisible for the Eclipse build system.

However, doing that will result in an Eclipse build error:

grafik
grafik.png822×328 21.3 KB

Is there a functionality to get the project substitution disabled by Buildship if the Eclipse project is closed?

I could imagine that Buildship should be able to do it automatically as it should have the projects states available.

Denis

P.S. This is slightly related to the issue https://github.com/eclipse/buildship/issues/511 too, I guess.

2

Related reading here where I was attempting a different approach to the same problem. I want to determine the open projects from a gradle plugin. The plugin would ultimately create a dynamic composite build by inspecting an eclipse workspace directory. I worked out how to list all projects and paths in an eclipse workspace, unfortunately I never found out how to get an open/closed boolean

Using this approach I was hoping that eclipse and gradle command line would share the same composite behaviour and build the same

Perhaps someone on this list could answer my stack overflow question of how to inspect an eclipse workspace and determine which projects are closed? @donat?

3

This is an interesting workflow you are trying to implement. When we first prototyped the composite build support in Buildship, we had something very similar in mind. Unfortunately, the feature confused so many people we decided to revert everything and just do what anyway Buildship should do: keep the Gradle build behavior as close to the command line as possible. And in this case, it - unfortunately - means commenting-uncommenting includeBuild statements in the settings.gradle file.

But if you really want to implement this, there’s a solution. Buildship offers an Eclipse extension point which clients can use to contribute additional arguments to the build. I can imagine a custom plugin which passes the list of opened workspace project names and locations to the build.

4

Hmm.
I do not see why this should confuse some one. – Buildship is intended for setting up the Eclipse project meta data well. However, if I close a Eclipse project, this does not reflect the meta data state and results in an Eclipse error. … Not very nice.

Second, who before have used the Gradle STS plugin had exactly this behavior. And a lot of people understand Buildship as the replacement of Gradle STS (and want to use it that way). But this may prevent them from doing so.

Third, it may be controlled by an option in the Buildship configuration pane, disabled by default. This may avoid confusing people who have not expected it.

Having this feature would have a big productivity improvement, I guess. That way, you may use Gradle for Eclipse meta data generation but stay with the Eclipse build system (for what reason ever) and remain using Gradle on the build server, where no Eclipse is installed. At least, that is our work flow and methodology. … And it worked really well for for the last 3 years with Gradle (STS). @Rene know it. :wink: He has given a workshop to us.

5

@donat What do you think about introducing it as an optional configuration option disabled by default?

To make it more explicit, here is a screen shot of the according configuration check box in Gradle (STS) - look at the cursor and the tool tip.

gradle-sts-jar-mapping-on-open-close
gradle-sts-jar-mapping-on-open-close.png883×599 112 KB

6

Thanks for the hints, Lance!
However, in difference to you, I guess, I want to have it as a user only. I don’t want to implement it.
(To be honest, I do not have the skills currently to implement it in Eclipse.)

7

@kuniss just to be clear, my solution was to do this in a Gradle plugin, not in Eclipse. This has the benefit that both eclipse and Gradle command line would build exactly the same composite build

If I get an answer to the question, I could implement the Gradle plugin in a couple of hours

8

@donat, any thoughts about introducing an optional configuration option for that?

Should I open an issue on GitHub?

Would it make sense to start a poll about that?

9

Please go ahead and open a new issue on GitHub. There, we can discuss all the technical details. Also, we use the :+1:s on the issues to prioritize what should be implemented in the next release.