After deploy custom rule (like https://github.com/SonarSource/sonar-java/blob/master/java-checks/src/main/java/org/sonar/java/checks/UselessImportCheck.java), when I start SonarQube 4.2, following exception is thrown during sonar start:
Caused by: java.lang.ClassNotFoundException: com.sonar.sslr.api.AstAndTokenVisitor
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) ~[plexus-classworlds-2.2.3.jar:na]
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) ~[plexus-classworlds-2.2.3.jar:na]
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) ~[plexus-classworlds-2.2.3.jar:na]
... 44 common frames omitted
Above mentioned class should be found in sslr-core-1.19.2.jar, which I found in location sonarqube-4.2/web/deploy/plugins/squidjava/META-INF/lib/sslr-core-1.19.2.jar
Am I missing some step to enhnance default sonar libraries?
Currently installed plugins are(sonarqube-4.2/extensions/plugins):
sonarqube-4.2/extensions/plugins/sonar-checkstyle-plugin-2.1.jar
sonarqube-4.2/extensions/plugins/sonar-web-plugin-2.1.jar
sonarqube-4.2/extensions/plugins/sonar-jacoco-plugin-2.2.1.jar
sonarqube-4.2/extensions/plugins/sonar-java-plugin-2.2.1.jar
sonarqube-4.2/extensions/plugins/sonar-surefire-plugin-2.2.1.jar
sonarqube-4.2/extensions/plugins/sonar-pmd-plugin-2.2.jar
sonarqube-4.2/extensions/plugins/sonar-findbugs-plugin-2.2.1.jar
sonarqube-4.2/extensions/plugins/sonar-squid-java-plugin-2.2.1.jar
What should I do to prevent above mentioned exception(except undeploy mentioned custom plugin)?
Should be necessary libraries bundled directly in to the custom plugin? I expected sonar to have such libraries bundled.
Finally I found solution/explanation for the problem:
sonarqube-4.2/web/deploy/plugins/ directory is dynamically updated during sonar start from the sonarqube-4.2/extensions/plugins directory. Every plugin should have lib directory in his META-INF jar.Such lib directory should contain all necessary libraries.
In my case:
META-INF/lib/asm-5.0.1.jar
META-INF/lib/java-checks-2.2.1.jar
META-INF/lib/java-squid-2.2.1.jar
META-INF/lib/jaxen-1.1.4.jar
META-INF/lib/sslr-core-1.19.2.jar
META-INF/lib/sslr-squid-bridge-2.3.jar
META-INF/lib/sslr-xpath-1.19.2.jar
And META-INF/MANIFEST.MF must besides othet important definitions contain link to these libraries:
Plugin-Dependencies: META-INF/lib/java-checks-2.2.1.jar META-INF/lib/j
axen-1.1.4.jar META-INF/lib/sslr-squid-bridge-2.3.jar META-INF/lib/ss
lr-xpath-1.19.2.jar META-INF/lib/asm-5.0.1.jar META-INF/lib/sslr-core
-1.19.2.jar META-INF/lib/java-squid-2.2.1.jar
After these steps deploy success and plugin is ready to be used.
Above mentioned fact is may be clear for MAVEN users (there is lot of pom files),but gradle users must create such builds on their own and this information may be useful for them.
Good luck!
Related
Can you please help me with following error I'm facing in WAS9 environment:
In order to resolve the import
org.apache.cxf.binding.soap.SoapHeader
I added the following dependencies in my pom.xml:
cxf-api-2.7.7
cxf-rt-bindings-soap-2.7.7
But when I'm trying to run my application, I'm getting the following error.
Default Executor-thread-7] ([ ]) Controllerclass - org.apache.cxf.bus.extension.ExtensionException
at org.apache.cxf.bus.extension.Extension.load(Extension.java:222)
at org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(ExtensionManagerImpl.java:199)
at org.apache.cxf.bus.extension.ExtensionManagerImpl.initialize(ExtensionManagerImpl.java:118)
at org.apache.cxf.bus.extension.ExtensionManagerBus.doInitializeInternal(ExtensionManagerBus.java:147)
at org.apache.cxf.bus.CXFBusImpl.initialize(CXFBusImpl.java:191)
at com.ibm.ws.jaxws.bus.LibertyApplicationBusFactory.createBus(LibertyApplicationBusFactory.java:119)
at com.ibm.ws.jaxws.bus.LibertyApplicationBusFactory.createClientScopedBus(LibertyApplicationBusFactory.java:86)
at com.ibm.ws.jaxws.metadata.JaxWsClientMetaData.<init>(JaxWsClientMetaData.java:28)
at com.ibm.ws.jaxws.metadata.JaxWsModuleMetaData.getClientMetaData(JaxWsModuleMetaData.java:123)
at com.ibm.ws.jaxws.support.JaxWsMetaDataManager.getJaxWsClientMetaData(JaxWsMetaDataManager.java:84)
at com.ibm.ws.jaxws.support.JaxWsMetaDataManager.getJaxWsClientMetaData(JaxWsMetaDataManager.java:123)
at com.ibm.ws.jaxws.client.LibertyProviderImpl.createServiceDelegate(LibertyProviderImpl.java:56)
at javax.xml.ws.Service.<init>(Service.java:57)
Caused by: java.lang.InstantiationException:org.apache.cxf.bus.osgi.OSGIBusListener
at java.lang.Class.newInstance(Class.java:427)
at org.apache.cxf.bus.extension.Extension.load(Extension.java:218)
Caused by: java.lang.NoSuchMethodException:org.apache.cxf.bus.osgi.OSGIBusListener.<init>()
at java.lang.Class.getConstructor0(Class.java:3082)
at java.lang.Class.newInstance(Class.java:412)
The server where your WAS9 has been deployed has different version of the above jar file. You need to have same version of jar files both in your eclipse where you have developed your codes and the server where you are deploying the war or ear.
mavan dependency file pom.xml is used during your project compilation. It might add the jar in your binary under lib folder as well. But WAS9 might considering the one which is in server's CLASSPATH. Hence check your class path and replace that jar with the one which you have mentioned in your pom.xml file. Hope that will fix your issue.
We can eliminate this exception by adding webProfile-7.0 in our server.xml, but how ever this is not working with javaee-7.0 not sure, if one knows about how to handle this in javaee-7.0 please share your approach.
I've been working on an Eclipse plugin codebase that builds with Maven Tycho. I can provide some snippets that anyone asks for, but you can get the code at https://git.opendaylight.org/gerrit/#/admin/projects/yangide (I believe that should be open).
I usually test it with an "Eclipse Application" launch config, loading all the plugins in the workspace. This works.
I sometimes test it by referencing the update site zip that I build locally. This works most of the time.
Recently, someone else I work with has deployed the update site to a public URL (https://nexus.opendaylight.org/content/sites/p2repos/org.opendaylight.yangide). This was built from master.
When I install from this into a standalone Eclipse, at some point after startup I see the following error:
Exception:java.lang.LinkageError: org/antlr/v4/runtime/TokenStream
at org.antlr.v4.runtime.Parser.setInputStream(Parser.java:530)
at org.antlr.v4.runtime.Parser.<init>(Parser.java:182)
at org.opendaylight.yangtools.antlrv4.code.gen.YangParser.<init>(YangParser.java:188)
I've actually seen this same exception sometimes when testing with the locally built update site zip, but rarely. I'm seeing it every time with this deployed update site.
So I understand that "Linkage Error" means that the class had already been loaded by another classloader which conflicts with this.
So, I started it up again with "-verbose:class" to at least see some information about the loading of this class.
From this output, I saw the following:
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/frameworks/eclipse-neon/java-mars/eclipse/../../../../.p2/pool/plugins/net.sf.eclipsecs.checkstyle_6.16.0.201603042321/checkstyle-6.16.1-all.jar]
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/frameworks/eclipse-neon/java-mars/eclipse/configuration/org.eclipse.osgi/605/0/.cp/libs/antlr4-runtime-4.5.1.jar]
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/.m2/repository/org/antlr/antlr4-runtime/4.5.1/antlr4-runtime-4.5.1.jar]
Note that this plugin obtains several jars from a Maven repo, as opposed to a p2 repo, including the "antlr4-runtime-4.5.1.jar" file. Most of these jars are not available in a public p2 repo. One of the plugins uses the "copy" and "copy-dependencies" goals of the "maven-dependency-plugin" to get Maven artifacts, and then specifies the local paths to those jars in the "Bundle-ClassPath" property in the META-INF/MANIFEST.MF file. other plugins in the codebase specify that plugin as a dependency.
Update:
Note that I sometimes see the following variation of this in the log:
Exception in thread "Yang indexer" java.lang.LinkageError: loader constraint violation: loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) previously initiated loading for a different type with name "org/antlr/v4/runtime/TokenStream"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:272)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:588)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:540)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:527)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:324)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:327)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:402)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.antlr.v4.runtime.Parser.setInputStream(Parser.java:530)
Update:
I realized that it might be useful to add "-verbose:class" to the launch config test case, because that is not having this problem. When I searched for the same class reference in the output, I only saw one occurrence:
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/workspace3/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/../../../../../../../media/sf_laptophome/git/yangide/plugins/com.cisco.yangide.yangparser/libs/antlr4-runtime-4.5.1.jar]
Remember that this is just loading the plugins from the workspace. This path is essentially in my workspace. In any case, it never tried to load it from those other two jar files.
This was because the Checkstyle Eclipse plugin "leaked" another version of ANTLR into this other (yangide) Eclipse plugin which uses a Package-Import.
I have a project that has the following package structure
src/main/proj
-com.company.package
-appName
-morepackages
-appVersion2
-morepackages
sonar-runner.properties
sonarBuild.sh
sonar-runner-project2.properties
sonarBuildProject2.sh
As it stands, with the default properties file i can run the sonar report and it will generate a review for the whole project
sonar.projectKey=KEY
sonar.projectName=PROJNAME
sonar.projectVersion=1.0
sonar.host.url=someurl
#Path for sonar sources
sonar.sources=src/main/java
#Path for libraries
sonar.libraries=target/lib/*.jar
#Path for binaries
sonar.binaries=target/classes
#--------Default database
sonar.jdbc.url=someurl
sonar.jdbc.driver=com.mysql.jdbc.Driver
#----- Global database settings
sonar.jdbc.username=sonar
sonar.jdbc.password=sonar
#----- Default directory layout
sonar.java.source=1.6
sonar.java.target=1.6
sonar.sourceEncoding=UTF-8
Ideally however I would like to separate the two reports so i have one for the original package and one for the appVersion2 package. Now - as mentioned above I have created a separate properties file for each. Should i just point sonar.sources to the respective packages for each job to analyse or is there a better way to do this all in one property file?
Thanks
EDIT
My multi module attempt properties file looks as follows
sonar.projectKey=rootkey
sonar.projectName=rootname
sonar.projectVersion=1.0
sonar.host.url=rooturl
sonar.sources=src/main/java/
sonar.libraries=target/lib/*.jar
sonar.modules=module1,module2
sonar.sourceEncoding=UTF-8
#----- Global database settings
sonar.jdbc.username=user
sonar.jdbc.password=pass
sonar.java.source=1.7
sonar.java.target=1.7
#--------Default database
sonar.jdbc.url=url
sonar.jdbc.driver=com.mysql.jdbc.Driver
module1.sonar.projectName=proja
module2.sonar.projectName=projb
module1.sonar.projectKey=projakey
module2.sonar.projectKey=projbkey
#Path for sonar sources
module1.sonar.sources=src/main/java/app1code
module2.sonar.sources=src/main/java/app2code
#Path for binaries
module1.sonar.binaries=target/classes/app1binaries
module2.sonar.binaries=target/classes/app2binaries
I get an error in the output saying....
Exception in thread "main" org.sonar.runner.RunnerException: org.sonar.runner.RunnerException: The base directory of the module 'module1' does not exist: patthtoapp/module1
at org.sonar.runner.Runner.delegateExecution(Runner.java:288)
at org.sonar.runner.Runner.execute(Runner.java:151)
at org.sonar.runner.Main.execute(Main.java:84)
at org.sonar.runner.Main.main(Main.java:56)
Caused by: org.sonar.runner.RunnerException: The base directory of the module 'module1' does not exist: pathtoapp/module1
at org.sonar.runner.internal.batch.SonarProjectBuilder.setProjectBaseDir(SonarProjectBuilder.java:279)
at org.sonar.runner.internal.batch.SonarProjectBuilder.loadChildProject(SonarProjectBuilder.java:191)
at org.sonar.runner.internal.batch.SonarProjectBuilder.defineChildren(SonarProjectBuilder.java:169)
at org.sonar.runner.internal.batch.SonarProjectBuilder.generateProjectDefinition(SonarProjectBuilder.java:122)
at org.sonar.runner.internal.batch.Launcher.execute(Launcher.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.sonar.runner.Runner.delegateExecution(Runner.java:285)
You have to specify the projectBaseDir if the module name doesn't match you module directory.
Since both your module are located in ".", you can simply add the following to your sonar-project properties:
module1.sonar.projectBaseDir=.
module2.sonar.projectBaseDir=.
Sonar will handle your modules as components of the project:
EDIT
If both of your modules are located in the same source directory, define the same source folder for both and exclude the unwanted packages with sonar.exclusions:
module1.sonar.sources=src/main/java
module1.sonar.exclusions=app2code/**/*
module2.sonar.sources=src/main/java
module2.sonar.exclusions=app1code/**/*
More details about file exclusion
You can define a Multi-module project structure, then you can set the configuration for sonar in one properties file in the root folder of your project, (Way #1)
Do the build job on Jenkins first without Sonar configured. Then add Sonar, and run a build job again. Should fix the problem
I configured and I use Datanucleus JPA to connect to MySQL. I compile the classes and enhanced entities with datanucleus-enhancer-plugin. I can run my app using mvn exec:java and I can also run it after I create an archive with lib (jar dependencies).
The problem appears when I create a jar (jar-with-dependencies). I get this error:
javax.persistence.PersistenceException: Explicit persistence provider error(s) occurred for "mysql" after trying the following discovered implementations: org.datanucleus.api.jpa.PersistenceProviderImpl from provider: org.datanucleus.api.jpa.PersistenceProviderImpl
at javax.persistence.Persistence.createPersistenceException(Persistence.java:244)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:186)
at cantina.crawler.util.JpaUtil.getRdbmsEntityManager(JpaUtil.java:29)
at cantina.crawler.bolt.SiteDetectorBolt.prepare(SiteDetectorBolt.java:32)
at backtype.storm.daemon.executor$fn__4050$fn__4059.invoke(executor.clj:610)
at backtype.storm.util$async_loop$fn__465.invoke(util.clj:375)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.datanucleus.exceptions.NucleusException: Error creating handler of type "persistence" for metadata parsing : MetaData handler plugin "persistence" was not found. Please check your CLASSPATH and plugin specification.
at org.datanucleus.metadata.xml.MetaDataParser.parseMetaDataStream(MetaDataParser.java:269)
at org.datanucleus.metadata.xml.MetaDataParser.parseMetaDataURL(MetaDataParser.java:137)
at org.datanucleus.metadata.MetaDataUtils.parsePersistenceFiles(MetaDataUtils.java:956)
at org.datanucleus.api.jpa.JPAEntityManagerFactory.<init>(JPAEntityManagerFactory.java:342)
at org.datanucleus.api.jpa.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:91)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:152)
... 6 more
Caused by: org.datanucleus.exceptions.NucleusUserException: MetaData handler plugin "persistence" was not found. Please check your CLASSPATH and plugin specification.
at org.datanucleus.metadata.xml.MetaDataParser.parseMetaDataStream(MetaDataParser.java:263)
... 11 more
I unziped the jar and the datanucleus-core files are there. I can not figure out what is happening.
You've not bothered looking after MANIFEST.MF and plugin.xml files when you changed the jar(s). DataNucleus jars are packaged to allow the (OSGi-based) plugin mechanism to identify plugins and capabilities. You've disabled that by playing around with those jars, so get the consequences.
Solution : either use the jars as provided, or merge them correctly (in which case it's your responsibility)
I am trying out m2eclipse, the Eclipse plugin for Maven, and have noticed that the resources are now excluded from the build path of all my projects.
I have seen a question on the M2Eclipse FAQ page which seems to deal with this exact question, but the answer (paraphrased) seems to say that this is intentional to allow resource filtering, and everything Should Just Work.
However, when I run my application from within Eclipse, lots of my resources in dependent projects are failing to get found by my application.
I have tried my usual Eclipse waving-a-rubber-chicken actions (cleaning all projects, starting with -clean) to no avail. I'm sure I'm missing something fairly simple. Does anyone have any suggestions?
EDIT: Some digging in the m2 console has revealed that one of the projects is not building correctly. I get a ClassNotFoundException when it tries to find org.apache.maven.plugin.MojoFailureException in a custom plugin used to build one of the projects.
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'ourdemain:ourcustomplugin:2.0:process': Mojo execution failed.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
at org.maven.ide.eclipse.internal.project.DefaultBuildParticipant$1.execute(DefaultBuildParticipant.java:130)
at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:986)
at org.maven.ide.eclipse.internal.project.MavenProjectFacade.execute(MavenProjectFacade.java:320)
at org.maven.ide.eclipse.internal.project.DefaultBuildParticipant.executePostBuild(DefaultBuildParticipant.java:116)
at org.maven.ide.eclipse.internal.project.DefaultBuildParticipant.build(DefaultBuildParticipant.java:80)
at org.maven.ide.eclipse.internal.builder.MavenBuilder.build(MavenBuilder.java:84)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.apache.maven.plugin.PluginExecutionException: Mojo execution failed.
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:601)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
... 27 more
Caused by: org.apache.maven.plugin.MojoExecutionException: org/apache/maven/plugin/MojoFailureException
at org.codehaus.mojo.ruby.DefaultRubyMojo.execute(DefaultRubyMojo.java:98)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
... 28 more
Caused by: java.lang.NoClassDefFoundError: org/apache/maven/plugin/MojoFailureException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:587)
at org.jruby.javasupport.Java.new_proxy_instance(Java.java:570)
at org.jruby.javasupport.JavaInvokerSnew_proxy_instancexx1.call(Unknown Source)
at org.jruby.runtime.callback.InvocationCallback.execute(InvocationCallback.java:49)
at org.jruby.internal.runtime.methods.FullFunctionCallbackMethod.internalCall(FullFunctionCallbackMethod.java:79)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:79)
at org.jruby.evaluator.EvaluationState.callNode(EvaluationState.java:577)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:206)
at org.jruby.evaluator.EvaluationState.setupArgs(EvaluationState.java:2182)
at org.jruby.evaluator.EvaluationState.attrAssignNode(EvaluationState.java:481)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:191)
at org.jruby.evaluator.EvaluationState.blockNode(EvaluationState.java:522)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:200)
at org.jruby.evaluator.EvaluationState.eval(EvaluationState.java:163)
at org.jruby.internal.runtime.methods.DefaultMethod.internalCall(DefaultMethod.java:167)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:79)
at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:125)
at org.jruby.evaluator.EvaluationState.callNode(EvaluationState.java:564)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:206)
at org.jruby.evaluator.EvaluationState.callNode(EvaluationState.java:544)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:206)
at org.jruby.evaluator.EvaluationState.localAsgnNode(EvaluationState.java:1230)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:285)
at org.jruby.evaluator.EvaluationState.rescueNode(EvaluationState.java:1522)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:349)
at org.jruby.evaluator.EvaluationState.ensureNode(EvaluationState.java:980)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:246)
at org.jruby.evaluator.EvaluationState.eval(EvaluationState.java:163)
at org.jruby.internal.runtime.methods.DefaultMethod.internalCall(DefaultMethod.java:167)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:79)
at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:125)
at org.jruby.evaluator.EvaluationState.fCallNode(EvaluationState.java:1019)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:252)
at org.jruby.evaluator.EvaluationState.blockNode(EvaluationState.java:522)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:200)
at org.jruby.evaluator.EvaluationState.rootNode(EvaluationState.java:1622)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:355)
at org.jruby.evaluator.EvaluationState.eval(EvaluationState.java:163)
at org.jruby.Ruby.eval(Ruby.java:274)
at org.codehaus.plexus.component.jruby.JRubyRuntimeInvoker.runInterpreter(JRubyRuntimeInvoker.java:392)
at org.codehaus.plexus.component.jruby.JRubyRuntimeInvoker.invoke(JRubyRuntimeInvoker.java:313)
at org.codehaus.mojo.ruby.DefaultRubyMojo.execute(DefaultRubyMojo.java:81)
... 29 more
Caused by: java.lang.ClassNotFoundException: org.apache.maven.plugin.MojoFailureException
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
... 75 more
The resource filtering mentioned in the FAQ is run whenever the Maven builder is run on the project. In practice I've found this to be more trouble than it's worth as the Maven builder runs quite slowly, and is only run when configured (which by default is only on a full build), leaving you to scratch your head and wonder why your changes aren't picked up.
I tend to modify the Eclipse classpath to include src/main/resources. This is sufficient for most use cases.
For the cases where the simple approach doesn't work (for example if a dependent project has some complicated resource processing), I do as Robert suggests and turn off workspace resolution, then install the dependency to the local repository so it is included in the Maven classpath container.
Try switching between the embedded ( 3.0 AFAIK ) Maven runtime and the one you use to perform your builds ( locally installed ).
Maven installations http://img150.imageshack.us/img150/6193/m2eclipseinstallations.png