This message was deleted.

Then you get exactly the problem that the blog post talks about – that you need to know what exact dependencies are needed to get a certain capability, rather than just declaring that dependency. Right?

As a library producer, of course I know which dependencies should be implemented on which variant. But as a consumer, I would rather the variant brings all the main dependencies so that I only need to declare once. I just don't know if such behavior is a good convention.

The goal is for the consumer to avoid specifying dependencies for each capability, rather specifying the capability itself and allowing the plumbing to take it from there. You can , of course, subvert that, with all the inherent risks as noted in the blog post.

I think you both misunderstand what @Hendra Anggrian tries to say. Of course you can add such a dependency. Most often you have that dependency anyway as the variants code extend some interfaces or similar of the main dependency. But also often the variant just a runtime dependency for the downstream projects and the main variant is an implementation or api dependency. Depends on the exact details of the situation.

Yeah, I think I understand the question now. So what you are after, Hendra, is being able to just have this in your consuming gradle file – correct?

dependencies {
    implementation("org.apache.pdfbox:pdfbox:2.0.17") {
        capabilities {
           requireCapability("org.apache.pdfbox:pdfbox-signing")
        }
    }
}

@Vampire @Simon Kågedal Reimer Yes, for the sake of simplicity, I would rather

pdfbox-signing

retains all the dependencies of

pdfbox

so that it can be imported once. Since it doesn’t make sense to use the feature without main artifact anyway. Unless of course it is discouraged due to performance issue or even programming standard.

As I said, it depends on the exact situation. If the consumer for example only uses code from

pdfbox-signing

and

pdfbox-signing

implements some interface of

pdfbox

, then you have what you want already anyway. If the consumer for example uses code from

pdfbox

and

pdfbox-signing

, it is cleaner to also declare both dependencies as

implementation

(or

api

if appropriate) dependencies. If the consumer for example only uses code from

pdfbox

but activates some runtime behavior by depending on

pdfbox-signing

, he should have

pdfbox

as an

implementation

(or

api

if appropriate) dependency and

pdfbox-signing

as

runtime-only

dependency. ...

Thanks for taking time exaplaining, and long live Gradle!