Using composite projects and share something different than the default jar?

Help/Discuss
1

Hello.
I am playing around using composite projects and substitutions. This works nicely when you only need “the standard jar file” but else I am fairly confused how you could share/subtitute anything else.
So for example:
Producer

artifacts{
    add("default", project.projectDir.resolve("localization"))
}

Gives me my artifact localization

--------------------------------------------------
Variant default
--------------------------------------------------
Configuration for default artifacts.

Capabilities
    - Ums.LocalizationResources.LookAndFeel:ClientLnF-Common:unspecified (default capability)
Artifacts
    - build\libs\ClientLnF-Common.jar (artifactType = jar)
    - localization

So I was asuming the consume could use somehow depend on this artifact like so:

dependencies.add("localization", "Ums.LocalizationResources.LookAndFeel:ClientLnF-Common:1.0-SNAPSHOT" ) {
    artifact{
        name="localization"
       extension=""
    }
}

But gradle is not able to resolve such a dependency.

  > Could not find localization (project :umslocalizationresources:LookAndFeel:ClientLnF-Common).

I am not quite sure if it would help my cause to use capabilites and or attributes and or excplicitely declared substitutions?
There is also the compose depends notation like so:

tasks.register("run") {
    dependsOn(gradle.includedBuild("my-app").task(":app:run"))
}

However artifact sharing is not mentioned and it looks a bit like what is mentioned as antipattern. So in summary is possible at all do share anything else than the default jar using composite projects and if yes how?

2

You should never add artifacts to the “default” configuration.
Instead you should indeed declare proper feature variants.
Whether you will use capability or attributes depends on the exact use-case.
If you for example want to have a “localization” artifacts of all dependencies on the compileClasspath, you would indeed use some attributes and then have a configuration or artifact view that is derived from that configuration and requests those other attributes.
If you for example just want to say “here I want the localization of that dependency”, then a capability might be fine.

3

And manual substitution rules are usually just duct-tape for being inconsistent somewhere or needing to use another persons project that is inconsistent.

4

You should never add artifacts to the “default” configuration.

I usually wouldnt use the default configuration, but the Documentation states under Cases where composite build substitutions won’t work

When a configuration other than default is published.

So I assumed it only works for the “default” configuration? But thats not the case? So you would say in a composite build its should generally be possible to consume consume artifacts from includedBuilds if wired up correctly?
Best regards

5

I think that section is way too negative, if not even wrong.
For example using composite build with maven-publish works perfectly fine and I cannot remember a time where it did not work.

Yes, consuming artifacts from included builds works perfectly fine usually.
If you try something and get into a struggle, you might share an MCVE to get more concrete help too.

6

Ok Thanks got it to working. trying to hack around by specifying the artifact name/extension did not working but configuring attributes on the consuming configuration seems to work just fine

1 Like