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?
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.
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.
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
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”?
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
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.
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.