Per Maven docs provided scope "is much like compile, but indicates you
expect the JDK or a container to provide the dependency at runtime.
For example, when building a web application for the Java Enterprise
Edition, you would set the dependency on the Servlet API and related
Java EE APIs to scope provided because the web container provides
those classes. A dependency with this scope is added to the classpath
used for compilation and test, but not the runtime classpath. It is
My team has noticed a number of artifacts using provided as more of a
compileOnly scope. That is, they want the dependency on the compile
time classpath, but do not want it on the runtime classpath. They do
not expect the web container, JVM, or anything else to put it on the
Is this an acceptable use of provided, and if so should we update the
docs? Or is this a hack and misuse of provided scope that is likely to
Well the use case appears to be the same as Gradle’s compileOnly, which as the name states, it’s used for compilation only and it’s not required for execution. Also, dependencies set in compileOnly are never exported to consumers, so in a way, with current Maven semantics Gradle’s compileOnly ~= Maven provided scope + <optional>true</optional>.
On 2020-07-29T12:22:33 +0200
Michael Osipov <[hidden email]> wrote:
> I think your usage is correct. Maybe the docs aren't sharp enough saying
> that those case just examples which require a provided scope. You can,
> of course, improve the docs in such a fashion.
> Out of couriosity, can you give you can example for your usecase?
I frequently use `provided` for compile-time only annotations. For
example, the immutables.org generator uses annotations to generate
immutable record types. The OSGi bundle annotations are processed by
the bnd-* plugin family and allow for adding extra information to OSGi
manifests in jar files. None of those annotations are retained, and we
don't expect anything to be available at runtime.