We Keep Coding

Cannot find annotation method 'value()' in type 'aQute.bnd.annotation.spi.ServiceConsumer' with Tomcat

I have a Java 11 project embedding Tomcat:
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-core</artifactId>
<version>10.1.0</version>
</dependency>
The Tomcat-specific code is in a subproject with only two classes. When I compile using Maven 3.8.6 and Java 17 using -Xlint:all, I see the following warning for that subproject:
[WARNING] Cannot find annotation method 'value()' in type 'aQute.bnd.annotation.spi.ServiceConsumer': class file for aQute.bnd.annotation.spi.ServiceConsumer not found
Doing a bit of searching brings up similar (but not exact) things, such as Lombok Issue #2145, which hints that I may need to add some sort of extra dependency such as biz.aQute.bnd:bndlib or org.osgi:osgi.annotation. But even after adding those dependencies, the warning remains.
Where is this error coming from, and what does it mean? I don't have any #ServiceConsumer annotation in my source code, and I couldn't find any in the Tomcat classes I'm extending, either. How can I make it go away?
I filed Tomcat Bug 66299.

I discussed this on the Tomcat users mailing list users#tomcat.apache.org (thanks Mark), and here's what is happening:
Tomcat effectively has two builds:
What I call the Tomcat "primary build" uses Ant with build.xml, which compiles the source files, creates all the JARs and binaries, and publishes them to Maven Central (Nexus).
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 Tomcat gets this annotation from biz.aQute.bnd:biz.aQute.bnd:6.3.1, which is apparently some aggregate JAR; the same annotation can be found in the smaller biz.aQute.bnd:biz.aQute.bnd.annotation:6.3.1.
The aQute.bnd.annotation.spi.ServiceConsumer annotation source code uses the OSGi annotation org.osgi.annotation.bundle.Requirement. Currently this annotation can be found in org.osgi:osgi.annotation:8.1.0.
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.
If you want to inform Maven and javac where these classes are so that they will not appear missing (if you are compiling with some variations of -Xlint), but that they nevertheless will not be needed at runtime (and technically aren't even needed at compile time in a secondary build) and should not be distributed in the resulting JAR, you can note them in your pom.xml file using the provided scope.
<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>
Maven will download these artifacts during your build thereby removing the warning, but they will not be included in the resulting artifacts of your build.

Does Mojo's AspectJ Maven Plugin work with jdk 9+?

I have a project that uses Mojo's AspectJ Maven Plugin. It works fine with jdk 8. When I try to switch to jdk14, the build fails with the following error:
[ERROR] Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.11:compile (default) on project AspectJDemo: Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.11:compile failed: Plugin org.codehaus.mojo:aspectj-maven-plugin:1.11 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:13.0.2 at specified path /usr/local/Cellar/openjdk/13.0.2+8_2/libexec/openjdk.jdk/Contents/Home/../lib/tools.jar -> [Help 1]
Mojo's website confirms that this file is a required dependency. However, according to this tools.jar has been removed since jdk 9. I have tried to provide a hardcoded path to this jar file in my dependencies like this:
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.8</version>
<scope>system</scope>
<systemPath>/path/to/tools.jar</systemPath>
</dependency>
But then the build completely fails as if it stops recognizing Java entirely. I get numerous errors such as:
[ERROR] can't find critical required type java.lang.Object
<unknown source file>:<no line information>
Does this mean Mojo's AspectJ Maven Plugin does not support jdk9+? Any idea on how I could resolve this is appreciated.

Update 2021-10-26: Because someone asked in a comment, a short overview of the status quo:
I as a co-maintainer of AspectJ proper am also maintaining the AspectJ.dev AspectJ Maven Plugin, because Nick's version is no longer maintained. The current version dev.aspectj:aspectj-maven-plugin:1.13.1 supports Java 17 and by default uses AspectJ 1.9.8.RC1 which also fully supports Java 17. It has more features than the other upstream and forked variants and is the variant I recommend. It can also parse version numbers greater than 17, i.e. in the future you can simply upgrade the AspectJ plugin dependency and increase the Java compliance level without having to upgrade the plugin version as such, unless you need new plugin features.
Lately there also was some activity at Mojohaus, mostly because I asked them if they could declare their plugin as deprecated, as there was no release in 3.5 years and support questions and PRs were being ignored for a long time. When they noticed that I published my own version, because as an AspectJ contributor I was concerned that Maven users had been left alone for such a long time, they merged in some (not all) of my changes and released version 1.14.0 which supports Java 16, but not Java 17.
Having said that, I recommend this plugin:
<dependency>
<groupId>dev.aspectj</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.13.1</version>
</dependency>
Previous version of this answer (now obsolete): The plugin has not been maintained since Java 8, but there is a fork with a pull request to be accepted up-stream. Because Mojohaus has no active maintainer for the plugin and the fork's developer has not been granted access rights to take over and push out an upstream release yet, for now just use this fork:
<dependency>
<groupId>com.nickwongdev</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.12.6</version>
</dependency>
I have used it for a long time, it is reliable and works at least up to Java 13. Even the latest version of IntelliJ IDEA automatically recognises it as an alternative to the Mojohaus version because this process has taken so long already.
P.S.: There is not need to provide hard-coded paths, just use the alternative plugin. :-)

How come my pom.xml dependency isn't found for my Jenkins plugin?

My pom.xml has this dependency:
<dependency>
<groupId>net.sf.json-lib</groupId>
<artifactId>json-lib</artifactId>
<version>2.4</version>
<classifier>jdk15</classifier>
</dependency>
When I use the XMLSerializer it throws an exception: java.lang.NoClassDefFoundError: nu/xom/Node
If I run the class locally and add the JAR to my classpath, everything works as expected. I'm running this class as a Jenkins plugin so I don't expect to be manually defining classpath - I figured that's what Maven should be handling.
It's important to note that Jenkins plugins require me uploading an hpi file that is created from Maven. It is not running based on the output jar. If I go on Jenkins box and manually put the xom JAR into WEB-INF/libs, it works. But obviously that means this plugin wouldn't for other people, which is self-defeating.
Here is minimal code causing error: https://github.com/DaveStein/parser-sample
The Readme has exact repro steps.
Note on chosen answer
The PR to my sample repo got me most of the way to where I needed to be. I did have a few other issues that had to get resolved, but the JSONObject conflict was the core problem. I took out all GlobalConfiguration as Jesse's PR suggested. The only other issue that might concern a future viewer was some glitch when using xom as explicit dependency while also using a higher version than 1.626 for org.jenkins-ci.plugins at the time of this post.

Jenkins core bundles json-lib. (A forked copy, not that it matters for purposes of this question.) It does not bundle the optional dependency¹ XOM, whatever that is. When your plugin loads XmlSerializer.class, it gets defined by the class loader for Jenkins core, which then attempts to link against classes such as nu.xom.Node. Since this is not available in the defining loader of XmlSerializer—the Jenkins core class loader (more or less jenkins.war!/WEB-INF/lib/*.jar)—you get an error. The fact that a class by that name is accessible in your plugin class loader is of no import, excuse the pun.
If your plugin needs to use its own versions of classes which are normally bundled in Jenkins core and exposed to plugins implicitly, then it needs to not only bundle those JARs (a regular compile-scoped Maven dependency suffices for that purpose), but to also use the pluginFirstClassLoader option. Before attempting to do so, you had better understand Java class loading semantics thoroughly, or you will be lost in a maze of cryptic² ClassCastExceptions and LinkageErrors.
By the way the mvn hpi:run command normally used to test plugin code iteratively does not simulate a realistic class loading regime. So if you are using pluginFirstClassLoader or any other tricks in this space, always double-check the resulting class loading behavior by (re-)installing an *.hpi in a sample Jenkins instance, for example using /pluginManager/advanced, or the install-plugin CLI command. Judging by your description, you were already doing that (and perhaps unaware of hpi:run).
¹The original sin here is use of optional dependencies. json-lib should rather have defined a distinct artifact json-lib-xom with hard dependencies on json-lib and xom. That would ensure that any given class loader can either see XmlSerializer and its dependencies, or neither.
²No progress on JDK-6273389, alas. Marked as a duplicate, but what it is a duplicate of, I am not sure. Theoretically Java 9 modules make questions like this obsolete—by imposing such onerous restrictions that applications like Jenkins could not use that module system to begin with.

please google "noclassdeffounderror vs class not found" , this error means the class dependency is in fact found but is not available in run time.
Try these steps:
Run mvn clean package and mvn clean install
Check if your maven environment is correct and has latest jars
Check if the installed target project contains the required jars
Check if dependency type is selected as runtime and not only as
compile time in pom.xml
Here is an example of using runtime dependency:
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-b</artifactId>
<version>1.0</version>
<type>bar</type>
<scope>runtime</scope>
</dependency>

My guess is that the local version of the XOM jar is not the same as the one that is used in your Maven version. To verify use the dependency:list Maven command to list out all your dependencies. Verify if the XOM dependency listed is the same version as the local jar.

Probably error on jenkins occurred while this dependency has been loaded for the first time and now it's considered as complete. Try to remove dependency from jenkins' maven local repository and re-run. That might help you

maven version tag [1.0,) does not work

I have the following dependency defined in my pom.xml
<dependency>
<groupId>runtime_shared</groupId>
<artifactId>org.boofcv</artifactId>
<version>[1.0,)</version>
</dependency>
with which I wanted to say "Take all the jars starting from version 1.0". I guess this is the correct way.
I have two versions in my local repository (.m2/repository) and I need both of these jars to have a successful compilation. However, I get an error saying that some packages do not exist. I checked the debug output and saw that maven only considers one of the jars (the last version) during the compilation, disregards the other one. And when I looked at the error message closely, I noticed that the packages it is talking about, are in the jar which is disregarded.
[DEBUG] /home/user/.m2/repository/runtime_shared/org.boofcv/1.0.2/org.boofcv-1.0.2.jar
Does anyone know why isn't version tag working?

You are referring to a syntax unique to the maven enforcer plugin.
Such syntax like [1.0,) is not valid for normal use of maven projects.
As per Jens' comment, you should specify a concrete version.
Here is the plugin documentation

Maven Run Error "maven-clean-plugin:2.5 or one of its dependencies could not be resolved"

Using İntelliJIdea, I Downloaded my project from Subversion for 12 times.
Deleted .m2/repository for 7-8 times.
Reimported, downloaded source for 15 times. Tried every possibilities but still cannot run my project.
Here is my Maven run profile and project hierarchy
and here this is my maven output
[ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-clean-plugin:jar:2.5 has not been downloaded from it before. -> [Help 1]
http://paste.ubuntu.com/10613835/
There is nothing wrong with project or maven files. I'm running it on my work computer. But not in my personel.
Update1: After I deleted "-o" parameter in maven run configuration. Here is my new log Logs after deletig "-o" paramter and here is image url http://i.hizliresim.com/Lp6dDJ.png
Update2: I run this command on cmd,
C:\MAYA\MAD4>mvn dependency:tree -Dverbose the result is success. And also saw C:\Users\tayfuny\.m2\repository\org\codehaus\plexus\plexus-digest\1.0\plexus-di‌​gest-1.0.jar in my dir. Here is latest maven output http://i.hizliresim.com/XBgD07.png

Update: Its early in the morning here in Switzerland - i have overseen you specified the -o parameter in your run configuration in the section Command line:. This is the console parameter to let Maven work offline ;) Remove it and you should be all good. Source: http://books.sonatype.com/mvnref-book/reference/running-sect-options.html
Update 2: Alright the initial problem is solved - your log however shows two more things to fix (one of them optionally but very recomended): 1.) The warnings at the very start of the build imply you have duplicate dependency/version declarations - those should be easy fixable. You can for example use mvn dependency:tree -Dverbose to get a overview on the duplicates (and which definition takes place in the end). The second is a actuall build error. I dont know about the install plugin you are using but i guess that you are missing this dependency: http://mvnrepository.com/artifact/org.codehaus.plexus/plexus-digest/1.0 (or another one containing the class that could not be found - adjust version as needed as well).
Answer regarding offline mode:
Remove the parameter -o when running maven unless you want to work in offline mode and with your local repository only.
Another probable cause is explicitly setting Maven to work in offline mode (e.g. only consult the local repository to resolve dependencies) from within the IDE itself (which will result in calling Maven with the -o parameter behind the scenes).
General Settings/ Project Settings:
File -> Settings -> Build, Execution, Deployment -> Build Tools -> Maven
(The very first option Work offline should be deactivated/ deselected unless you realy want to work with the local repository only).
Those settings are inherited by Maven-run configurations by default but may be overwritten at two levels
Default Run Configuration:
(Those default configs will be inherited by specific run configurations. Note that changes to the general settings apply to newly created run configurations only and will not be populated to existing ones).
Specific Run Configuration:
Make sure none of the options is selected. In the end if you use a specific launch configuration make sure the option is not selected in that specific configuration and change the higher levels for convenience if it makes sence)

EASY WAY
This should work for all similar errors.
This is how an error looks like
Could not resolve : org.apache.maven.plugins:maven-clean-plugin:jar:2.5
Could not resolve : (groupID):(artifactID):version
So what you actually need is a correct version of the clean plugin.
<dependency>
<groupId>(groupId)</groupId>
<artifactId>(artifactId)</artifactId>
<version>(version)</version>
<type>maven-plugin</type>
</dependency>
This will become something like this. Add this to dependencies section Pom.xml. Reload build.
<dependency>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M5</version>
<type>maven-plugin</type>
</dependency>
Reload build and IDE will automatically download these version of artefacts and
replace if there are other versions because your project needs these particular versions to run.
Do the same with other dependency errors. "Works every time".