Develop Reference

Unable to derive module descriptor: Provider {class X} not in module

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.

IntelliJ won't accept FileTypeFactory

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!

New Grails 2.3 App gets created with ForkedTomcatServer.groovy errors

When I create a new "Grails Project" in GGTS-3.3.0 with Grails 2.3, I get several errors in ForkedTomcatServer.groovy. These are the errors I get:
Groovy:[Static type checking] - No such property: version for class:
org.codehaus.groovy.grails.plugins.GrailsPluginInfo ForkedTomcatServer.groovy /testapp/.link_to_grails_plugins/tomcat-7.0.42/src/groovy/org/grails/plugins/tomcat/fork line
165
Groovy:[Static type checking] - No such property: descriptor for
class:
org.codehaus.groovy.grails.plugins.GrailsPluginInfo ForkedTomcatServer.groovy /testapp/.link_to_grails_plugins/tomcat-7.0.42/src/groovy/org/grails/plugins/tomcat/fork line
166
These are the lines of code referenced in the errors:
GrailsPluginInfo info = GrailsPluginUtils.getPluginBuildSettings().getPluginInfoForName('tomcat')
String jarName = "grails-plugin-tomcat-${info.version}.jar"
File jar = info.descriptor.file.parentFile.listFiles().find { File f -> f.name.equals(jarName) }
I have not made any changes whatsoever. I just clicked File -> New -> Grails Project and the output has these errors. I have made several different projects and they all generate the same way.
Why is this happening and how can I fix it?

To fix this issue you should install Groovy 2.1. In GGTS the Groovy 2.1 is available from the dashboard. This solved my the problem.

From 2.3.0 Latest News updated yesterday
We are aware that the IDEs will require some updates to work with
Grails 2.3.0. If you plan to use 2.3.0 soon, please use the Intellij
IDEA EAPs and latest GGTS milestone releases which include updates to
work with Grails 2.3.0

I have the same issue to use Grails 2.3.0 with GGTS 3.3.0. After I installed the Groovy 2.1 from dashboard, this problem is gone. The same issue of the compiler version mismatch is also gone after install the latest Groovy

Workaround. Open ForkedTomcatServer.groovy, comment out the #CompileStatic, save file. The error will disappear. Now you can go ahead and un-comment that line and the error is gone. Groovy magic!

I also had this issue. Installtion of the Groovy 2.1 compiler sorted that out.
One of my errors said my workspace did not match the project and I could right-click and Eclipse fixed that part. Real issue was that I needed to update my compiler to 2.1.

Apache IVY error message? : impossible to get artifacts when data has not been loaded

hey all, I'm getting the following error when trying to build a project via SBT in scala
[info] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
java.lang.IllegalStateException: impossible to get artifacts
when data has not been loaded. IvyNode = log4j#log4j;1.2.14
I don't see any of my projects referencing 1.2.14, nor is it in my .m2 or .ivy repositories. Not sure where to look for this one
a full error dump is here: http://pastebin.com/pM7NUhY0
thanks

Seems that this is related to IVY-987 and should be fixed in ivy 2.1.0-RC1.

I saw this recently with a junit dependency and it kind of drove me nuts trying to fix it. In my case I had to remove the "test" scope from the dependency declaration (in this case in SBT with Scala).
Anyway, hope it helps someone.

compile error: The import xxxx cannot be resolved

I am developing a Java project using Eclipse. The project uses another project called engine, which I have added in my project build-path. As I need to call a dabo class, called House, in one of my project class, named Window, I have used the following code as usual:
import ee.asus.kernel.House;
I got however the following error in compiling time:
Exception in thread "main" java.lang.Error: Unresolved compilation problems:
The import ee cannot be resolved
House cannot be resolved to a type
House cannot be resolved to a type
House cannot be resolved to a type
at main.ee.asus.GUI.FrameWindow.Window.<init>(Window.java:10)
at main.ee.asus.GUI.StartApplication.main(StartApplication.java:13)
It's worth to point out that my prject and the dabo project use the same directory/packages names. Does anyone have a clue where the error may be?

The error can't resolve the first part of the package name: ee. Are you sure the package starts with ee? I see your Window class package starts with main.ee, does your engine project start with the same package structure?

I sometimes get weird behaviour with missing class files etc. when Eclipse is out of sync with the filesystem.
You could try refreshing all of your projects and doing a full rebuild.

I have been experiencing the same problem. I have an app A1(tablet version app) calling another app A2(phone version app). Upon calling, I see the same error message:
java.lang.Error: Unresolved compilation problems:
The import xxxxx cannot be resolved
xxxx cannot be resolved to a type
xxxx cannot be resolved to a type
xxxx cannot be resolved to a type
After poking around for a while, I realized the problem was the A2 doesn't run on tablet at all. It's weird because the immediate previous version of A2 runs perfectly on the same tablet(I have been on board only for 1 month). So I decided there was something wrong in the build config.
Finally, I fixed the problem by changing the order of Java Build Path. Although I have no idea why it worked, hopefully this will shed some light on your problem.

Look for the House class in your second project, opens it and see what package it is in.
(line "package xxx.yyy.zzz;" at the beginning of the House.java file)
Then make sure your Window.java file (class main.ee.asus.GUI.FrameWindow.Window) does have the line "import xxx.yyy.zzz.House;" in it.

In my case it was a version conflict.
I'm using maven and updated many packages and bumped versions of many projects. Maybe the reactor built mixed something up, or the transitive dependencies weren't up-to-date, or it was a change in a project without a version increment. However, rebuilding that project explicitly via maven fixed the problem.
Edit: When I think about it, it might also have been a conflict between eclipse's auto-build and building via maven on the command line.