Open sdavids opened 2 months ago
Fwiw, because JSpecify can be used at runtime, I'd favor api
in Gradle (and not-provided, not-optional in Maven). Those who don't use the annotations at runtime, and don't want to ship the JSpecify JAR in their application can safely exclude it from their deliverables, but the rule should be that it's "included by default".
(it is an anti-pattern to mark annotation dependencies as compileOnly
or compileOnlyApi
, it depends on the annotation retention: source → compileOnly
, class → compileOnlyApi
, runtime → api
; in Maven: source → provided/optional is the closest you can do, class or runtime → compile)
I'd favor
api
in Gradle
For libraries, yes. For applications, I would think compileOnly
would be fine, no?
If you're using the java
(or application
) plugin in Gradle, rather than java-library
, for an application, then you don't have api
and compileOnlyApi
, and you only have to choose between implementation
and compileOnly
, which is what I hinted above: if you don't use the annotations at runtime, and don't want to ship the JSpecify JAR in your application, you can safely use compileOnly
, otherwise use implementation
.
Please add a section to the README similar to the one at @API Guardian.
You might also want to add it to either Start Here and/or Nullness User Guide.
Maven
or
Related: #389
Gradle
The Java Library plugin configurations
or
or
or
If it is not
compileOnlyApi
you might want to add a link to an appropriate FAQ entry.