Re: provided as compileOnly
On 2020-07-29T12:22:33 +0200 Michael Osipov 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. -- Mark Raynsford | https://www.io7m.com pgplTCSWArvcw.pgp Description: OpenPGP digital signature
Re: provided as compileOnly
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 + true. Sent from my primitive tricorder > On 29 Jul 2020, at 12:22, Michael Osipov wrote: > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: provided as compileOnly
Am 2020-07-29 um 12:18 schrieb Elliotte Rusty Harold: 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 not transitive." 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 runtime classpath. 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 cause problems? 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? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
provided as compileOnly
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 not transitive." 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 runtime classpath. 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 cause problems? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
