# Optional dependencies are not optional

DevFeed: [Optional dependencies are not optional](<https://devfeed.tech/articles/optional-dependencies-are-not-optional-24675.md>)

Original publisher: [Read original article](<https://blog.gradle.org/optional-dependencies>)

Author: Cédric Champeau

Published: 2020-01-07T05:00:00Z

Content type: tutorial

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Maven](<https://devfeed.tech/topics/maven.md>), [Library](<https://devfeed.tech/topics/library.md>), [Cryptography](<https://devfeed.tech/topics/cryptography.md>), [Logging](<https://devfeed.tech/topics/logging.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [cryptography](<https://devfeed.tech/tags/cryptography.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [library](<https://devfeed.tech/tags/library.md>), [optional](<https://devfeed.tech/tags/optional.md>)

## AI overview

The article explains that so-called optional dependencies are actually required when a specific library feature is used. Using Gradle, Apache Maven, Apache PDFBox, and BouncyCastle as examples, it describes how optional dependencies are omitted during transitive dependency resolution, leaving consumers to determine and add the required components manually. It introduces feature-based dependency modeling as a clearer approach.

## Source excerpt

In a previous blog post, we demonstrated how capabilities could be used to elegantly solve the problem of having multiple logging frameworks on the classpath. In this post, we will again use this concept in a different context: optional dependencies. At Gradle, we often say that there are no optional dependencies: there are dependencies which are required if you use a specific feature. Let's explain why. Optional dependencies Until recently, Gradle didn't offer any way to publish optional dependencies, which is something which puzzled a number of Apache Maven™ users. To understand in what context optional dependencies are used, let's look at a real world project. The Apache PDFBox library declares the following optional dependencies in its POM file: <dependencies> <dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcmail-jdk15on</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk15on</artifactId> <optional>true</optional> </dependency> </dependencies> Those are 2 dependencies on a specific component, the BouncyCastle cryptography library. Now let's imagine your project depends on PDFBox, either using Gradle: dependencies { implementation("org.apache.pdfbox:pdfbox:2.0.17") } or using Apache Maven™: <dependencies> <dependency> <groupId>org.apache.pdfbox</groupId> <artifactId>pdfbox</artifactId> <version>2.0.17</version> </dependency> </dependencies> Now if you look at the dependencies that both Maven and Gradle resolve, you will see that the Bouncycastle library is absent. This is because it's defined as an optional dependency. There are multiple problems with optional dependencies as they are defined today: Library authors know why a dependency is optional, but consumers don't: how do you know when you should add bcprov-jdk15on? Optional dependencies are mixed up: how do you know when to add bcprov-jdk15on and if bcmail-jdk15on should be added as well? Optional dependencies are ignored