Exciting new Buildship Features coming up

Hi Ivica,

thanks for giving Buildship 2.0 a try. As far as I’m aware, classifiers are not yet supported by composite build, which explains the exception you are seeing.

@daz do you have any further info on this? Are dependencies with classifiers something that’s already on the radar?

Cheers,
Stefan

I think the issue will be with the following dependency declaration, which declares a dependency on a particular artifact (not classifier):

project.dependencies.create(dependency + "@conf")

I presume that there is some logic in project1 that publishes this artifact, and that this logic is not being taken into account in composite build. Are you using ivy-publish or maven-publish to publish project1 to a repository? Or perhaps the artifactory-publish plugin?

@daz we use maven publish

The maven-publish and ivy-publish plugins are not yet supported with composite builds.

Is there any more information on this?

I am trying to get a “composite” build setup in eclipse but it is not working.

I have a “commons” library that I would like to use in other projects that are part of a multi-module project. Basically a structure like this:

Workspace
\- commons
|   \- build.gradle
\- projectA
   \- projectA-1
   |   \- build.gradle
   \- projectA-2
   |   \- build.gradle
   \- build.gradle
   \- settings.gradle

So from projects “projectA-1” and “projectA-2” I would like to have the dependency substitution work for “commons”. Is this something that is supported yet?
Right now it still seems to be resolving to the “commons” jar from maven.
If it is supposed to work based on project.group and project.name, then I think I have that set up correctly, but let me know if there is anything I can check to make sure I have everything set up correctly.

Thanks,
Michael

Actually, I got this working. And my structure was not exactly accurate. I usually don’t have my “projects” directly under my “workspace” folder. So all of my projects are checked out into a “git” folder, then I have a separate Workspace folder. Then in elcipse I just “import” my projects.

With that structure the dependency substitution does not work (hopefully just because this feature is still in development or is this really not going to be supported).

But once I made my workspace folder the root of where all my projects are, then the dependency substitution started working. Hopefully this helps someone else and helps the devs with another use case.

The location has nothing to do with dependency substitution. I always use a separate git folder too…

There are only two requirements, as stated before:

  • all projects in the workspace must use the exact same Gradle version
  • that version must be >= 2.14

My guess is that you had some project in your workspace with a different Gradle version and now you’ve removed it/updated the version.

Cheers,
Stefan

@daz is there a way to disable composite build?

Currently there is no explicit way. But of you import any project with a different Gradle version, it will be deactivated.

I tried dependency substitution with a homegrown project setup (see Eclipse: detect projects that are dependencies). It is working, though I had to close the Gradle sources (of the whole distribution) first, because resolution of projects kept running forever :slight_smile:

As you wrote in Exciting new Buildship Features coming up the feature does recognize artifacts with markers project.name and project.group. Can you tell if you plan to recognize artifacts with different markers? Especially for different “artifactIds” because I do not like the project’s name (hence the folder name of the checked out repository) to be the artifact’s Id.

So if I have a project “projectA” with groupId “my.group” that produces a “api-1.0.jar” under “build/libs/”, then will dependency substitution recognize it when I refer to a dependency of “compile 'my.group:api:1.0”?

Yes, this will be supported by composite builds.

Btw your project name does not need to be the same as the folder name, You can change them in settings.gradle.

Yea. Gradle is set up using wrapper script. Currently on gradle 2.3

Unrelated to the error, the latest beta seems to break multi project builds as the transitive dependencies of a project dependency are not being included. I had to revert back to the 2.0.0.v20160714-1012 version to get it to work again

As mentioned before, composite build needs Gradle >= 2.14.

I’m sorry. That was a typo. Currently on grade 2.14

Is there any way I can enable debug logs to identify the issue here?

The version @atomic_ice has mentioned is not available from the eclipse buildship milestone 2.x update site. Is this by purpose? When will a version be published to the milestone update site?

The milestone update site contains the latest state and should work just fine. We understand from your feedback that the current approach is confusing , as it only works if all projects in the workspace have exactly the same Gradle version.

Over the next few weeks we will significantly change how composite builds are integrated into Buildship. Instead of creating an automatic composite, you will be able to import composites defined in settings.gradle. This is a new feature planned for Gradle 3.1. This will give you much better control over the composite and how dependencies are substituted. We will keep you posted about new milestones as soon as they are available.

Is there a sample composite build project available that I can look at? I see lot of talk on this feature online but so far haven’t come across a single working project.

Composite Builds are a new feature in Gradle 3.1, so please watch for the release candidate soon :slight_smile:

IDE support will follow in Gradle 3.2/Buildship 2.0

I have two advices:

  1. After gradle task executed, “Package Explorer” did not refresh automatically;
  2. The .jar file list belongs to “Project and External Dependencies” can not be sorted.

Hello

I just installed Buildship version 1.0.20.v20160901-0734. I did realise since previous versions that when a new project is created never are created by default the src/main/resources and src/test/resources locations.

Is it the expected or normal behaviour? I don’t know if has sense through the IDE perhaps indicate it either of them should be created or not.

Not sure I should create an issue in Github for this.

Thank you.