I have an Eclipse based application which is being ported from Java 8 to Java 11. Since javax.xml and friends was removed from the JDK, I had to add it as an Import-Package to every plug-in that needed them.
Now however, when run this code
Marshaller marshaller = JAXBContext.newInstance(MyClass.class).createMarshaller();
I get the following exception:
java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:135)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:480)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:184)
I can add com.sun.xml.bind, which should have the dependency, but nothing happens. This is understandable, since OSGi rules prevents hacking into another plug-in via reflection.
However I cannot add Require-Bundle nor Import-Package to the JDK or the bundle around javax.xml.bind.
There is a bug surrounding this issue, but I cannot find a good solution for my application in the comments. Still I assume it can be fixed for an Eclipse application, else Eclipse itself shouldn't be able to run on Java 11.
How do I fix this exception?
We found an OSGi compatible way to fix this exception:
add the following implementations to the target platform
org.apache.servicemix.specs.jaxb-api-2.2 (from Maven central)
com.sun.xml.bind (from the Eclipse platform; this is the one that contains the ContextFactory)
make sure these bundles are started with your application
make sure the Apache bundle is started before everything else
So in Tycho, this would look like this:
<bundleStartLevel>
<bundle>
<id>org.apache.servicemix.specs.jaxb-api-2.2</id>
<autoStart>true</autoStart>
<level>1</level>
</bundle>
</bundleStartLevel>
<dependencies>
<dependency>
<artifactId>org.eclipse.e4.rcp</artifactId>
<type>eclipse-feature</type>
</dependency>
<dependency>
<type>p2-installable-unit</type>
<artifactId>org.apache.servicemix.specs.jaxb-api-2.2</artifactId>
</dependency>
<dependency>
<type>p2-installable-unit</type>
<artifactId>com.sun.xml.bind</artifactId>
</dependency>
</dependencies>
I'm too using jaxb in my application (JMSToolBox) and too migrated from Java 1.8 to Java 11 and didn't had this problem
In my plugin, I have a "lib" directory with the"jaxb-ri"jar and its dependencies (from maven):
jaxb-api-2.3.1.jar
jaxb-runtime-2.3.2.jar
javax.activation-api-1.2.0.jar
istack-commons-runtime-3.0.7.jar
Then the plugin references those jars (MANIFEST.MF + build.properties) and I don't have any problem
The plugin is here
Related
I am supposed to get a "app-name"-grailsPlugins folder/module under my project structure, however I am not getting it.
enter image description here
I am not sure if it's a maven issue, since I am getting a sucessful "maven compile" as well as "grails compile" but my friend is able to get it on his mac.
Because of that IntelliJ isn't able to recognize a valid class from the spring-security-core plugin. It doesn't affects me as much as of now, but I shouldn't have any line of code "redlined" and IntelliJ should be able to recognize that class.
This is my dependency within the pom.xml:
<groupId>org.grails.plugins</groupId>
<artifactId>spring-security-core</artifactId>
<version>${grails.spring-security.version}</version>
<scope>runtime</scope>
<type>zip</type>
<exclusions>
<!--<exclusion>
<!– can make global exclusion in BuildConfig –>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>-->
<exclusion>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
</exclusion>
</exclusions>
</dependency>
Any help is appreciated. I have been looking everywhere so far.
Screenshot of project structure with missing grailsPlugins module with maven 3.8.3
UPDATE
STEPS TO REPRODUCE
Install sdkman
Use sdkman to install Grails 2.4.5
Use Grails 2.4.5 command-line "grails create-app (name of your grails project)" to create grails project.
Open grails project inside IntelliJ
Go to terminal inside IntelliJ and use Grails command "grails create-pom (your chosen group id [com.samplemaven]) to create Maven pom.xml file.
Go to IntelliJ File|Project Structure | Module and you will see that IntelliJ doesn't automatically generate app-name-grailsPlugins module
Sample Grails 2.4.5 project in IntelliJ with Maven integration
All of a sudden all my Mule Maven projects are throwing this error when running mvn clean test:
java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException
at org.mule.tck.junit4.AbstractMuleTestCase.(AbstractMuleTestCase.java:71)
I can add a dependency for it, but I shoudln't really have to.
Nothings changed in my code. I am using Mule 3.4
You need commons-cli.jar in your classpath, add this Maven dependency to your pom
<dependency>
<groupId>commons-cli</groupId>
<artifactId>commons-cli</artifactId>
<version>1.1</version>
</dependency>
Update: OP's code was fixed after adding commons-cli 1.1 dependency.
Issue description and how to fix it: http://ricston.com/blog/mule-classnotfoundexception-tests-commons-cli/
In a nutshell, you probably have an incorrect JAR named commons-cli-1.2. Delete that and rerun your maven build. You should be good after that.
If the follogin dependency in available in the POM. it should be working fine.
<dependency>
<groupId>org.mule.tests</groupId>
<artifactId>mule-tests-functional</artifactId>
<version>3.4.0</version>
<scope>test</scope>
</dependency>
Then use mvn clean compile to update the dependency.
mvn eclipse:clean eclipse:eclipse clean compile
Hope this helps.
Maven behaviour isn't reproducible from one run to the next: apart from generic network problems and repository corruption problems, anything might be updated automatically at any time, breaking any step of the execution, even if you don't change any of your files.
Your error message about a class in some Apache Commons library suggests a disagreement between the version of that library Mule should be using (one that has the ParseException class) and the library version it actually loads (without the class and causing the exception).
Plausible version mismatch scenarios include an update to a buggy new version of Mule (maybe only to a wrong or corrupted POM) which specifies an incompatible library version, or a random upgrade or downgrade of the latest library version in your repository as a consequence of adding or updating something unrelated to Mule.
Analysis suggestions:
What plugins in your Maven repository have a snapshot version? Which ones of these snapshots were updated around the time the error first appeared?
Which library jars, and which versions, include the ParseException class? What depends on specific versions or on the latest version of those jars?
I am trying to add a WSDL module to my existing application, but I'm struggling to get the dependencies resolved.
According to their website, this is the correct dependency
<dependency>
<groupId>org.ow2.easywsdl</groupId>
<artifactId>easywsdl-wsdl</artifactId>
<version>2.1</version>
</dependency>
After a search (search.maven.org), I already changed the version to 2.3 and there are a bunch of files that are downloaded into my local repository, but when running the application (with the websites demo code), I bump into this error:
java.lang.ClassNotFoundException: com.ebmwebsourcing.easycommons.uri.UriManager
And I believe it has something to do with the missing artifacts :
com.ebmwebsourcing.easycommons:easycommons.uri:jar:1.1
com.ebmwebsourcing.easycommons:easycommons.logger:jar:1.1
In particular the first one. Now, I'm relatively new to using Maven... How would I go about solving this?
Thanks.
The solution is to add the petalslink repository. Appearantly the standard maven repository doesn't contain the easycommons dependency. The petalslink repository does.
OK, I'm trying to get a validator working with a jsp form.. Have just started using maven, so it's all a bit new... what's the best way of locating which repository I should be selecting for the above class? I already have the following entries for validation:
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.0.0.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator-annotation-processor</artifactId>
<version>4.1.0.Final</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>4.1.0.Final</version>
</dependency>
I tried loading hibernate itself, but that broke the build: I'm using eclipse for persistence, and building fails after dragging in a huge number of prerequisite libraries.
I figured that I should get a better strategy than just stabbing away with repositories..
Just to be clear: I'm getting the error:
java.lang.NoClassDefFoundError: Could not initialize class org.hibernate.validator.engine.ConfigurationImpl
This should be in the hibernate-validator dependency, so not behaving as I would expect.
Do you have slf4j-api on the classpath (this should be pulled in by HV, but just to make sure)?
The NoClassDefFoundError doesn't mean that ConfigurationImpl is not available, but it couldn't be loaded (typically due to problems in the static initializer or by imports of the loaded class which are not available).
A side note on using the annotation processor: instead of adding it as project dependency you can also use it via the Maven annotation processor plugin. That way you can't accidentally import classes from it in your project. The set-up is described in detail in the Hibernate Validator reference guide.
OP probably won't need it anymore, but maybe somebody else will.
I've had a similar problem with combination of Hibernate Validator 4.3 Final and slf4j 1.5.11
Finally I've found pair of versions that are willing to work together namely:
-Hibernate Validator Final 4.2
-slf4j 1.6.6
We've just recently converted our project to using Maven for builds and dependency management, and after the conversion I'm getting the following exception while trying to run any JSFUnit tests in my project.
Exception class=[java.lang.UnsupportedOperationException]
com.gargoylesoftware.htmlunit.ScriptException: CSSRule com.steadystate.css.dom.CSSCharsetRuleImpl is not yet supported.
at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
at net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
...
All the dependencies and JARs for JSFUnit were pulled with Maven using the JBoss repository (http://repository.jboss.com/maven2/).
We're using the following dependencies in the project:
jboss-jsfunit-core 1.2.0.Final
jboss-jsfunit-richfaces 1.2.0.Final
richfaces-ui 3.3.2.GA
openfaces 2.0
JSF 1.2_12
Facelets 1.1.14
Before the dependencies were being managed by Maven, we were able to run our JSFUnit tests just fine. I was able to semi-fix the issue by using a ss_css2.jar file that someone had tucked into our WEB-INF/lib directory (from before the Maven conversion). I'm hoping to find out if there's something else I can do to fix the dependencies in Maven rather than resorting to managing some of the dependencies myself.
You're very likely getting an "incompatible" version of HtmlUnit or another JAR (pulled transitively). Try with the version you were using previously and declare it under the dependencyManagement section, e.g.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>net.sourceforge.htmlunit</groupId>
<artifactId>htmlunit</artifactId>
<version>2.7</version><!-- put "your" version here -->
</dependency>
</dependencies>
</dependencyManagement>
Or, if you changed any version, try to revert to the exact previous state (by the way, could you clarify the differences between the previous versions and the one currently used?).
Update: It appears that the problem was related to the version of the cssparser artifact. I hadn't all the required elements to figure this out but the OP did :)