Confused about composite builds setup with Buildship 2.0

Help/Discuss Buildship
1

Hello,

I’ve been waiting with a lot of excitement for the final release of Buildship 2.0 as I’m hoping this will solve a lot of hurdles in my development process. However after trying it out, I’m left confused as to how it is supposed to work. I hope you can clear this out.

Say I have 2 multi-project builds: my-libraries and my-apps and my-apps depends on some of the projects of my-libraries:

/my-libraries
    /library1
    /library2
/my-apps
    /app1
    /app2

I haven’t configured any of the builds as composite builds for now. I imported both my-libraries and my-apps into the same Eclipse workspace. I was expecting the projects within my-apps to be setup in Eclipse to depend on the my-libraries projects but right now this isn’t the case. Do I now need to configure the projects as composite builds as described here (https://docs.gradle.org/current/userguide/composite_builds.html)? In earlier snaphot releases of Buildship 2.0 it used to be done automatically under the hood.

I also tried to find some verbose logs to debug this issue but couldn’t find any. Could you indicate how to enable them?

Last note: In Gradle’s documentation there’s a note that says that composite builds don’t work with the plugin maven-publish. I do have this plugin applied via some of my own plugins. I didn’t quite understood why the maven-publish plugin would break composite builds. That said I’m happy to not apply the plugin when included in a composite build. So my 2nd question is whether there’s an easy way to detect when a project is part of a composite build?

I appreciate any help you can provide. Thank you

2

You need to. There is no “automagic composite” like in the early snapshots, it was causing lots of trouble and confusion.

It doesn’t say it will break. It just won’t take into account the configuration of maven-publish, but only use project.name and project.group. So those need to match the dependency declaration.

Cheers,
Stefan

3

Hi Stefan,

Thank you for your response. This was helpful as I was starting to think the snapshots versions were working better than the release one.

That said do you know if transitive dependencies have known issues? I’m running into some problem.

I have the following directory structure:

REPO1/projectA
REPO1/projectB
REPO2/projectC
REPO2/projectD

projectB directly depends on projectA
projectC directly depends on projectB
and projectD directly depends on projectC

I have a composite build defined with

includeBuild ../../REPO1
includeBuild ../../REPO2

After imported the composite project, I see that projectC is properly defined with a direct dependency on projectA and projectB. However projectD is defined only with a dependency on projectC. And because projectC doesn’t export its dependencies (which I think is correct as of some version of gradle 2.x) it’s missing my latest code changes that are in projectA and projectB.

I’m using Gradle 3.3 everywhere and I have buildship 2.0.0.v20170111-1029

Thank you

4

This should work fine, so either you have found a bug or something is wrong with the project setup. Could you create a reproducible example on GitHub?

5

Hi Stefan,

I built a very basic reproducible test case here: https://github.com/GuiForget/buildship-test/. Let me know if you can’t reproduce.

Cheers,

6

@Gui_Forget I imported the example project and it works just fine with Buildship 2.0.1:

Screen Shot 2017-03-10 at 14.25.39.png706×544 58.3 KB

Do you have any init scripts that might be influencing the eclipse model?

7

Hi @st_oehme so to understand this correctly, I manually need to write this into the settings.gradle so that buildship can do the workspace resolution?
Is there a way to configure composite builds only for “local development” mode? Usually I do not have any control over checkout locations on my build server and actually on the build server I really do not want this composite build setup.
What did you mean by confusion with the “automagic composite”? Isn’t this mostly expected if I have the depending projects inside the same workspace?

Would it be possible to introduce some kind of eclipse preference flag that enables the “automagic composite”?

1 Like
8

We don’t plan to reintroduce the implicit composite. It would mean that all Gradle builds in the workspace would be running under the same Gradle version, which almost never works, since users usually check out many different projects in their workspace.

We’d be happy to have a nice UI to create composites on the fly though and would welcome a PR for this. IntelliJ has that feature and it has proven popular with their users.

1 Like
9

Well, that is a step back from Maven. That it is a either implicit or explicitly via ui support, shows the popularity of the mentioned IntelliJ support.