I am getting this error message when I try to compile my new modularized Java 11 application:
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for C:\Users\inter\.m2\repository\xalan\xalan\2.7.2\xalan-2.7.2.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class org.apache.bsf.BSFManager not in module
This appears to be an issue from a dependency of a dependency. I can't even find which module is pulling it in so I can update it.
I am using openjdk 11.0.2, IntelliJ 2018.3.4, Maven
Any advice how I can troubleshoot or fix this? I have found very little documentation on this issue.
Xalan
I had a look at their bug tracker following their index page and wasn't able to find this reported and not sure how actively is the library being maintained either.
General Explanation
Just to explain what has caused the issue in your code, I would share a screenshot and then try to add details around it.
So within the JAR that for version 2.7.2, there are service declarations (META-INF/services) which include org.apache.xalan.extensions.bsf.BSFManager as one of them. The service file here has to indicate the Provider thereby for itself and the class is supposed to be present on the modulepath to be resolved for reliable configuration of modules.
In this case for the module xalan(automatic module), the service listed doesn't have the provider class packaged within the dependency itself. (See the package org.apache, it doesn't further have package bsf and the class BSFManager thereby. Hence the exception as you get.
Short term hack
One of the tweaks to get that resolved would be to get update the library jar (patch it) and get rid of the service file if you're not using it. Or to add the provider copied from the corresponding artifact.
If you don't directly depend on this artifact or its parent dependencies, you can let those remain on the --classpath and get resolved as an unnamed module for your application.
Long term solve
An ideal way would be to report this to the maintainers and getting it resolved. It depends though on how actively are they maintaining it e.g. the last release for xalan was almost 5 years back, might just want to look for an actively participated alternative in my opinion.
I tried to install update for TestNG in eclipse:
"Help -> Check for updates -> deselect all and select TestNG check box. Then
install latest version i installed the version which starts with 7.2.0.
It fixed the issue for me.
Related
I'm trying to migrate a Java application that uses Tika from OracleJDK 1.8 to OPenJDK 13.
My IDE is Eclipse.
I have created the file module-info.java to indicate the required modules for my application.
In order to be able to use Tika classes such as AbstractParser, Detector, etc., I have added requires org.apache.tika.core; in module-info.java.
My code also uses the class org.apache.tika.parser.pdf.PDFParserConfig to extract embedded images:
PDFParserConfig pdfConfig = new PDFParserConfig();
pdfConfig.setExtractInlineImages(true);
context.set(PDFParserConfig.class, pdfConfig);'
I get the compilation error:
PDFParserConfig cannot be resolved to a type
Eclipse suggests to add requires org.apache.tika.parsers; to module-info.java: Eclipse suggestion screenshot.
When I add this module requirement to module-info.java, the application compiles properly.
That is, at this stage we have included in module-info.java:
module myapp {
/** others ... */
requires org.apache.tika.core;
requires org.apache.tika.parsers;
}
However, when trying to execute the compiled application, we get the error:
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for C:\Users\Admin\.m2\repository\org\apache\tika\tika-parsers\1.24\tika-parsers-1.24.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class org.apache.tika.parser.onenote.OneNoteParser not in module
Inspecting the project Libraries in Eclipse, I can see that tika-core and tika-parsers (v1.24) are both modular: Eclipse Java Build Path
In conclusion: If I don't add org.apache.tika.parsers as a required module, the application won't compile, and if I add it I get the runtime error saying org.apache.tika.parser.onenote.OneNoteParser is not in the module.
I have inspected the JAR files for these packages to see the dependencies they have. The core packages seems to be right:
$ jar --file=tika-core-1.24.jar --describe-module
No module descriptor found. Derived automatic module.
org.apache.tika.core#1.24 automatic
requires java.base mandated
contains org.apache.tika
contains org.apache.tika.concurrent
contains org.apache.tika.config
contains org.apache.tika.detect
contains org.apache.tika.embedder
contains org.apache.tika.exception
contains org.apache.tika.extractor
contains org.apache.tika.fork
contains org.apache.tika.io
contains org.apache.tika.language
contains org.apache.tika.language.detect
contains org.apache.tika.language.translate
contains org.apache.tika.metadata
contains org.apache.tika.mime
contains org.apache.tika.parser
contains org.apache.tika.parser.digest
contains org.apache.tika.parser.external
contains org.apache.tika.sax
contains org.apache.tika.sax.xpath
contains org.apache.tika.utils
...but the 'parsers' jar gives an error:
$ jar --file=tika-parsers-1.24.jar --describe-module
Unable to derive module descriptor for: tika-parsers-1.24.jar
Provider class org.apache.tika.parser.onenote.OneNoteParser not in module
Does this mean the jar package for parsers is not well formed?
Is there any workaround for this?
Thank you.
EDIT:
If I try with version 1.24.1, I get the execution error:
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for C:\Users\Admin\.m2\repository\org\apache\tika\tika-parsers\1.24.1\tika-parsers-1.24.1.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class org.apache.tika.parser.external.CompositeExternalParser not in module
That is: the failing class is CompositeExternalParser instead of OneNoreParser.
Inspecting META-INF/services/org.apache.tika.parser.Parser of tika-parsers-1.42.1.jarI can see the entryorg.apache.tika.parser.external.CompositeExternalParser` but the package does not contain this class.
So, it seems to be an error in this META-INF file. Id this due to an error when compiling the package and submitting it to Maven Central?
I've found a JIRA issue, TIKA-2929, where they say "Apache Tika needs to be on the Java Classpath, not the module path". I've tried this, but, as explained before, I get a compilation error if I don't add it to the module path and set requires org.apache.tika.parsers;.
This is a hard puzzle...
Ran into the same issues.
Also found the faulty entries in
org.apache.tika.parser.Parser (and also org.apache.tika.parser.Detector) in META-INF/services/
A quick fix is to ...
Unpack those files
delete the lines that seem to reference non existing classes
pack them back into the jar
My project compiled after that.
For sure no longterm solution, but since even older versions i tried ran into that problem, it might help out some people.
I am upgrading my play-services-ads library from version 12 to version 18.1:
dependencies {
api 'com.google.android.gms:play-services-ads:18.1.0'
}
The problem is that the compilation fails with this error:
.gradle/caches/transforms-1/files-1.1/play-services-ads-identifier-17.0.0.aar/75b3c9fbdc51199269673bd2fa8b6cfe/jars/classes.jar(com/google/android/gms/ads/identifier/AdvertisingIdClient.class): warning: Cannot find annotation method 'value()' in type 'GuardedBy': class file for javax.annotation.concurrent.GuardedBy not found
I took away all the usages for AdvertisingIdClient and left only the import, but the problem persists:
import com.google.android.gms.ads.identifier.AdvertisingIdClient;
Is there anything I am doing wrong?
com.google.android.gms:play-services-ads:18.1.0 depends upon com.google.android.gms:play-services-ads-identifier:17.0.0, among other libraries.
Your error indicates that com.google.android.gms:play-services-ads-identifier:17.0.0 references javax.annotation.concurrent.GuardedBy. However, that class is not in the Android SDK. The POM file for com.google.android.gms:play-services-ads-identifier:17.0.0 should be referencing a library that has an implementation of that class, but it does not seem to.
One library that has an implementation of that class is com.google.code.findbugs:jsr305. Adding a dependency on com.google.code.findbugs:jsr305 for a recent version (e.g., 3.0.2) gave you that class, satisfying the compiler.
So, there appears to be a bug in the Play Services SDK packaging, which my workaround resolves. You might want to add a comment in your module's build.gradle file to consider removing the com.google.code.findbugs:jsr305 if a future update to com.google.android.gms:play-services-ads fixes this bug.
I was using HiveMQ Client version 1.0.1 but I decided to update to the recently released version 1.1. I completely started from scratch and imported the project as a Gradle project and tried to build. The build work only after ignoring a few failed tests. I'm getting 3 errors in 3 different classes. I realize this is likely related to the Dagger dependency injection tool and I had already successfully built the project and added the directory of build/generated/source/apt/main/ to my build path as noted by my previous stack post where I had issues with a DaggerSingletonComponent not being found: How to fix DaggerSingletonComponent not resolved in HiveMQ (MQTT protocol) . This seems to be a new issue and I'm not sure what's wrong. I tried rebuilding by project but the errors still persist. I've left some screenshot below as well as the specific errors.
HiveMQ:
https://github.com/hivemq/hivemq-community-edition
https://github.com/hivemq/hivemq-mqtt-client
Errors:
The constructor MqttChannelInitializer(MqttClientConfig, MqttConnAckFlow, MqttEncoder, MqttConnectHandler, MqttDisconnectHandler, MqttAuthHandler, Lazy) is undefined
The constructor MqttSession(MqttClientConfig, MqttSubscriptionHandler, MqttIncomingQosHandler, MqttOutgoingQosHandler) is undefined
The method provideBootstrap(NettyEventLoopProvider, MqttChannelInitializer) in the type ConnectionModule is not applicable for the arguments (MqttClientConfig, NettyEventLoopProvider, MqttChannelInitializer)
Screenshots:
Executing ./gradlew clean build on the command line will fix your error.
But I also think that the real solution for your use case is to create a new empty project (gradle or maven) and add the client library as a dependency, like described here: https://hivemq.github.io/hivemq-mqtt-client/docs/installation.html
The issue turned out to be caused by an issue with the source folder in the directory build/generated/source/apt/main/ not having the option “Update exclusion filters in other source folders to solve nesting” selected. Selecting that option solved all of the errors.
A project runs on Google App Engine. The project has dependency that uses a class that can't be invoked on App Engine due to security constraints (it's not on the whitelist). My (very hacky) solution was to just copy a modified version of that class into my project (matching the original Class's name and package) that doesn't need the restricted class. This works on both dev and live, I assume because my source appears in the classpath before my external dependencies.
To make it a bit cleaner, I decided to put my modified version of that class into it's own project that can be packaged up in a jar and published for anyone else to use should they face this problem.
Here's my build.gradle:
// my jar that has 'fixed' version of Class.
compile files('path/to/my-hack-0.0.1.jar')
// dependency that includes class that won't run on appengine
compile 'org.elasticsearch:elasticsearch:1.4.4'
On my local dev server, this works fine, the code finds my hacked version of the class first at runtime. On live, for some unknown reason, the version in the elasticsearch dependency is loaded first.
I know having two versions of the same class in the classpath isn't ideal but I was hoping I could reliably force my version to be at the start of the classpath. Any ideas? Alternatively, is there a better way to solve this problem?
Not really sure if this is what people visiting this question were looking for, but this was what my problem and a solution that I reached at.
Jar A: contains class XYZ
Jar B: also contains class XYZ
My Project needs Jar B on the classpath before Jar A to be able to get compiled.
Problem is Gradle sorts the dependencies based on alphabetical order post resolving them which meant Jar B will be coming after Jar A in the generated classpath leading to error while compiling.
Solution:
Declare a custom configuration and patch the compileClasspath. This is how the relevant portion of build.gradle might look like.
configurations {
priority
sourceSets.main.compileClasspath = configurations.priority + sourceSets.main.compileClasspath
}
dependencies {
priority 'org.blah:JarB:2.3'
compile 'org.blah:JarA:2.4'
...
}
It's the app engine classloader I should have been investigating, not gradle...
App Engine allows you to customise the class loader JAR ordering with a little bit of xml in your appengine-web.xml. In my case:
<class-loader-config>
<priority-specifier filename="my-hack-0.0.1.jar"/>
</class-loader-config>
This places my-hack-0.0.1.jar as the first JAR file to be searched for classes, barring those in the directory war/WEB-INF/classes/.
...Thanks to a nudge in the right direction from #Danilo Tommasina :)
UPDATE 2020:
I just hit the same problem again and came across my own question... This time, live appengine was loading a different version of org.json than was being loaded in dev. Very frustrating and no amount of fiddling the build script would fix it. For future searchers, if you're getting this:
java.lang.NoSuchMethodError: org.json.JSONObject.keySet()Ljava/util/Set;
It's because it's loading an old org.json dependency from god-knows-where. I fixed it by adding this to my appengine-web.xml:
<class-loader-config>
<priority-specifier filename="json-20180130.jar"/>
</class-loader-config>
You'll also need a matching dependency in build.gradle if you don't already have one:
compile 'org.json:json:20180130'
According to gradle dependencies documentation, the order of dependencies defines the order in the classpath. So, we can simply put the libraries in the correct order in "dependencies".
But beware! here are two rules with higher priorities:
For a dynamic version, a 'higher' static version is preferred over a 'lower' version.
Modules declared by a module descriptor file (Ivy or POM file) are preferred over modules that have an artifact file only.
I am attempting to follow the Language and File Type tutorial for JetBrains IntelliJ
It worked, once. Now (whatever I do) I receive an assertion failure stating that it was expecting an instance of FileTypeFactory and got my SimpleFileTypeFactory
My public class SimpleFileTypeFactory extends com.intellij.openapi.fileTypes.FileTypeFactory so I'm not sure how to react to this ...
Caused by: java.lang.AssertionError: Expected: class com.intellij.openapi.fileTypes.FileTypeFactory; Actual: class bengie.idea.SimpleFileTypeFactory
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.assertClass(ExtensionPointImpl.java:408)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.processAdapters(ExtensionPointImpl.java:242)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.getExtensions(ExtensionPointImpl.java:185)
... especially when Google has no matches for "Expected: class com.intellij.openapi.fileTypes.FileTypeFactory; Actual"
Has anyone resolved this sort of thing?
I was depending on a Maven module (actually, two of them) The rest of my project is built with Maven so it seemed logical and looked like it would work. I didn't remember the build seizing up when I added them, so I had forgotten about it. Removing the dependency, starting a debug session, uninstalling the plugin, rinse, repeat and I eventually stopped seeing error messages.
I've since stuffed the maven modules into a jar-with-dependencies and told the IntelliJ plugin module to load the resulting .jar No problems so far - Yay!