On 11/10/2022 16:36, Garret Wilson wrote:
Mark, with your help I've figured this out and resolved the issue. Let
me summarize and propose a more long-lasting solution. I don't expect
you to agree, but please humor me and and least point out anything I
understood incorrectly. (After all I need to go back and update the bug
report. And the Stack Overflow question.)
* Tomcat effectively has two builds:
1. The "primary build" uses Ant with `build.xml`, which compiles
the source files, creates all the JARs and binaries, and
publishes to Maven Central (Nexus).
2. Any "secondary build" by third parties using the published JARs
and POMs using e.g.
`org.apache.tomcat.embed:tomcat-embed-core:10.1.0` with Maven.
* The latest versions of direct dependencies are found in the Tomcat
repository inside `build.properties.default`.
* The primary build generates JPMS and OSGI metadata, so some classes
are annotated with the bnd annotation
`aQute.bnd.annotation.spi.ServiceConsumer`. Currently this
annotation come from `biz.aQute.bnd:biz.aQute.bnd.annotation:6.3.1`.
Not quite. Tomcat gets it from:
biz.aQute.bnd:biz.aQute.bnd:6.3.1
I'm guessing that bnd provides the same class in different JARs for
different use cases. I don't know if the annotations JAR would be
sufficient for your needs.
* The `aQute.bnd.annotation.spi.ServiceConsumer` annotation uses the
OSGi annotation `org.osgi.annotation.bundle.Requirement`. Currently
this annotation comes from `org.osgi:osgi.annotation:8.1.0`.
This is incorrect. bnd no longer depends on the OSGi JAR.
* The bnd and OSGi annotations remain part of the compiled classes
even though they are not used at runtime and are not technically
needed in any secondary builds.
* Thus any secondary Maven builds need to inform Maven that it can
download the bnd and OSGI annotations just to make sure that no
classes are missing during this secondary build process, but that
these artifacts are not needed at runtime and should not be
distributed in the resulting JAR. In Maven this is easily indicated
uses the `provided` scope.
This is not correct either. What you term secondary builds do not
require bnd in order to compile against the Tomcat JARs.
Thus in a perfect world, Tomcat would simply indicate in its published
POMs that these two dependencies contain necessary classes, but should
not be distributed, using the following:
```xml
<dependency>
<groupId>biz.aQute.bnd</groupId>
<artifactId>biz.aQute.bnd.annotation</artifactId>
<version>6.3.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi.annotation</artifactId>
<version>8.1.0</version>
<scope>provided</scope>
</dependency>
```
This would not negatively affect Tomcat one bit, yet it would arguably
provide "more complete information" for any secondary builds.
The negative impact is that all users of that JAR would be required to
download the bnd library to compile their project for no benefit to them.
Of course I can add those POM entries to my own secondary builds, and I
will. But it's less than ideal. First of all a developer has to go track
down exactly which dependencies are relevant. Secondly a developer has
to dig inside `build.properties.default` to find out what versions are
currently being used (and the versions of transitive dependencies are by
no means obvious). Tomcat already has most of this information at
primary build time, and could simply include it in the POM using the
variable interpolation system it already uses.
Finally someone might ask, "Why do you care? It's a warning—just ignore
it." Perhaps the person who asks this has never worked on a large
project for a client and everything was breaking all over the place, and
the build had 10,000 warnings and no one knew which of them actually
were important and which were simply benign warnings that had been
present for 15 years because of developer laziness. In any case, there
are mechanics who work day to day with a messy tool shop and still just
know where to find their tools; and other mechanics who like to keep
their tool shop clean and organized. The latter type of mechanic might
not be more or less competent, and it may not matter whether their tool
shop is messy if they are working alone.
In today's world in which most software will be worked on by many
developers across a multitude of dependencies, I prefer to keep a clean
and tidy shop (i.e. project build). Thus I address any warnings, and if
the warning is benign, I find a way to disable or suppress it.
Suppressing a benign warning is best done nearest to where it is being
generated, i.e. in this case within Tomcat itself, but since that isn't
likely to happen I'll update my own build, which is an acceptable
second-best option. At least now I know what's going on and how to
address it.
If you chose to enable additional warnings by using using Xlint:all
then you also have to accept that you'll need to take additional steps
to resolve some of those additional warnings. In this instance, you need
to add the bnd dependency.
To put this in perspective, that JAR has been using that annotation for
just over two years.
Maven Central stats show about 7.6 million downloads last month alone of
the tomcat-embed-core JAR.
Your is the only question ever received about this warning.
The cost of all those users being required to download a bnd jar for no
benefit to them far outweighs the cost of a single user being required
to add a dependency to their pom.
Mark
Garret
On 10/11/2022 1:34 AM, Mark Thomas wrote:
On 10/10/2022 13:34, Garret Wilson wrote:
On 10/10/2022 12:14 AM, Mark Thomas wrote:
…
That is a fairly old version. You should upgrade to the latest
version first.
I certainly will. I first went through a long list of linting
problems in the project; this was one of the things left over. I
wanted to understand it more.
If you want to fix the warning, those are not the correct dependencies.
If you want the exact dependencies used with 9.0.50 then you can
find them from the source code:
…
You want
bnd (not bndlib) 5.3.0
OSGi annotations 1.1.0
That's super helpful. I'll go look for those.
But could someone give a 1–3 sentence overview of what these
libraries are and why Tomcat uses them? Or is there a wiki page
explaining that already?
The bnd library is used to generate JPMS and OSGI metadata for the
Tomcat JARs. Most of the metadata is generated from scanning the JARs
but where code uses the ServiceLoader, the annotation is required so
that bnd can generate the correct service dependencies.
The annotation is only used by bnd during the build. It is not used at
runtime.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
