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.
This is a companion discussion topic for the original entry at https://blog.gradle.org/optional-dependencies
Sometimes I need a public static constant of a class. For example:
So I make spring web a dependency. I then puts an extra 20MB of dependency like spring core and others into my application. So I have to exclude everything explicitly.
Here comes optional into the picture. If a library is written with dependencies marked as optional, you can use anything from that library without negative consequences.
Usually a developer uses a “util” library for extending the capabilities of an already included dependency.
A util library collection often contains several “extensions” for several indipendent frameworks. A developer usually needs one or few features from it. And do not want to deal with excluding dependencies they do not need… In contrary a developer always knows which feature he needs and if it has additional optional dependency which is required, he always can insert that dependency directly into his project.
Optional is there for a reason for several years now. Stating that a widely used framework (maven in this case) is bad and we are way smarter than the people designed it shows arrogance not competency…