I hate to post this question because it has been asked for many versions of liquibase, but I cannot change the logging level for version 3.6.3. I've tried the suggestions for the other versions without any success...
POM:
<liquibase.logging>INFO</liquibase.logging>
and
<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>${liquibase.version}</version>
<configuration>
<logging>${liquibase.logging}</logging>
...
</configuration>
When I run mvn, I still get DEBUG level messages from Liquibase
07:09:29.541 [main] DEBUG liquibase.servicelocator.DefaultPackageScanClassResolver - Searching for all classes in package: liquibase/change using classloader: org.codehaus.plexus.classworlds.realm.ClassRealm
07:09:29.541 [main] DEBUG liquibase.servicelocator.DefaultPackageScanClassResolver - Getting resource URL for package: liquibase/change with classloader: ClassRealm[plugin>org.liquibase:liquibase-maven-plugin:3.6.3, parent: sun.misc.Launcher$AppClassLoader#7852e922]
07:09:29.542 [main] DEBUG liquibase.servicelocator.DefaultPackageScanClassResolver - URL from classloader: jar:file:/home/xxxxxxxxxxxxxx/.m2/repository/org/liquibase/liquibase-core/3.6.3/liquibase-core-3.6.3.jar!/liquibase/change/
07:09:29.543 [main] DEBUG liquibase.servicelocator.DefaultPackageScanClassResolver - Decoded urlPath: file:/home/xxxxxxxxxxxxxx/.m2/repository/org/liquibase/liquibase-core/3.6.3/liquibase-core-3.6.3.jar!/liquibase/change/ with protocol: jar0
etc.
I've also tried the -Dliquibase.logging=info on the mvn command line and I get the same results.
There were several bugs related to logging in Liquibase 3.6.x. These have been fixed in version 3.8.1 and greater.
Related
When I try to run a Gatling performance test with Karate, I get the following in the error log.
Simulation perf.SVTKarateSimulation started...
17:55:28.277 [GatlingSystem-akka.actor.default-dispatcher-2][ERROR][Action.scala:71] c.i.k.g.KarateAction - 'classpath:com/TCEU/KarateTests/Test.feature' crashed with 'j.l.NullPointerException', forwarding to the next one
This is how my pom file looks:
<plugin>
<groupId>io.gatling</groupId>
<artifactId>gatling-maven-plugin</artifactId>
<version>3.0.4</version>
<configuration>
<simulationsFolder>src/test/java</simulationsFolder>
<includes>
<include>perf.SVTKarateSimulation</include>
</includes>
<jvmArgs>
<jvmArg>-Dfile.encoding=UTF-8</jvmArg>
</jvmArgs>
</configuration>
</plugin>
And using Karate-Gatling 0.9.5.RC4
This is how my scala file:
package perf
import com.intuit.karate.gatling.PreDef._
import io.gatling.core.Predef._
import scala.concurrent.duration._
import io.gatling.http.Predef._
class SVTKarateSimulation extends Simulation {
val create = scenario("Get api").exec(karateFeature("classpath:com/TCEU/KarateTests/test.feature"))
setUp(
create.inject(rampUsers(10) during (10 seconds)))
}
And the test.feature file:
Feature: Gatling test
Background:
* url 'https://regres.in'
Scenario: Get api
Given path '/api/users/2'
When method GET
Then status 200
I looked at solutions provided in
Crashed with 'j.l.NullPointerException' when i try to run karate-gatling test reports
and also
https://github.com/intuit/karate/issues/404
But the solutions provided in that does not help either.
I am using Windows 10 with Eclipse Version: 2019-09 R (4.13.0).
I tried to run another project related feature file but that gave the same error so tried a simple test following a video tutorial - https://www.youtube.com/watch?v=RrRhndl-osY
Can someone kindly help please?
For the benefit of anyone else who faces this issue, the solution is to keep your pom.xml consistent with same version of Karate. My karate-gatling was 0.9.5.RC4 where as karate-apache was 0.9.4. When I made them both 0.9.5.RC4, I did not face these issues. Make sure pom.xml is consistent.
And if anyone runs into this kind of issue when compiling / running:
15:22:28.250 [main] ERROR io.gatling.compiler.ZincCompiler$ - one error found
15:22:28.252 [main] ERROR io.gatling.compiler.ZincCompiler$ - Compilation crashed
sbt.internal.inc.CompileFailed: null
at sbt.internal.inc.AnalyzingCompiler.call(AnalyzingCompiler.scala:242)
at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:111)
at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:90)
at sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$3(MixedAnalyzingCompiler.scala:82)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at sbt.internal.inc.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:133)
at sbt.internal.inc.MixedAnalyzingCompiler.compileScala$1(MixedAnalyzingCompiler.scala:73)
at sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:116)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.Incremental$.doCompile(Incremental.scala:106)
at sbt.internal.inc.Incremental$.$anonfun$compile$4(Incremental.scala:87)
at sbt.internal.inc.IncrementalCommon.recompileClasses(IncrementalCommon.scala:116)
at sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:63)
at sbt.internal.inc.Incremental$.$anonfun$compile$3(Incremental.scala:89)
at sbt.internal.inc.Incremental$.manageClassfiles(Incremental.scala:134)
at sbt.internal.inc.Incremental$.compile(Incremental.scala:80)
at sbt.internal.inc.IncrementalCompile$.apply(Compile.scala:67)
at sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:311)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:269)
at sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:159)
at sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:238)
at sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:69)
at io.gatling.compiler.ZincCompiler$.doCompile(ZincCompiler.scala:210)
at io.gatling.compiler.ZincCompiler$.delayedEndpoint$io$gatling$compiler$ZincCompiler$1(ZincCompiler.scala:215)
at io.gatling.compiler.ZincCompiler$delayedInit$body.apply(ZincCompiler.scala:39)
at scala.Function0.apply$mcV$sp(Function0.scala:39)
at scala.Function0.apply$mcV$sp$(Function0.scala:39)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:17)
at scala.App.$anonfun$main$1$adapted(App.scala:80)
at scala.collection.immutable.List.foreach(List.scala:392)
at scala.App.main(App.scala:80)
at scala.App.main$(App.scala:78)
at io.gatling.compiler.ZincCompiler$.main(ZincCompiler.scala:39)
at io.gatling.compiler.ZincCompiler.main(ZincCompiler.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at io.gatling.mojo.MainWithArgsInFile.runMain(MainWithArgsInFile.java:50)
at io.gatling.mojo.MainWithArgsInFile.main(MainWithArgsInFile.java:33)
This is likely to be because on Windows, the Java bin folder is not added to the System PATH. See the below thread for more details.
https://github.com/intuit/karate/issues/404#issuecomment-417630286
When I try to run a Gatling performance test with Karate, I get the following in the error log.
Simulation perf.SVTKarateSimulation started...
17:55:28.277 [GatlingSystem-akka.actor.default-dispatcher-2][ERROR][Action.scala:71] c.i.k.g.KarateAction - 'classpath:com/TCEU/KarateTests/Test.feature' crashed with 'j.l.NullPointerException', forwarding to the next one
This is how my pom file looks:
<plugin>
<groupId>io.gatling</groupId>
<artifactId>gatling-maven-plugin</artifactId>
<version>3.0.4</version>
<configuration>
<simulationsFolder>src/test/java</simulationsFolder>
<includes>
<include>perf.SVTKarateSimulation</include>
</includes>
<jvmArgs>
<jvmArg>-Dfile.encoding=UTF-8</jvmArg>
</jvmArgs>
</configuration>
</plugin>
And using Karate-Gatling 0.9.5.RC4
This is how my scala file:
package perf
import com.intuit.karate.gatling.PreDef._
import io.gatling.core.Predef._
import scala.concurrent.duration._
import io.gatling.http.Predef._
class SVTKarateSimulation extends Simulation {
val create = scenario("Get api").exec(karateFeature("classpath:com/TCEU/KarateTests/test.feature"))
setUp(
create.inject(rampUsers(10) during (10 seconds)))
}
And the test.feature file:
Feature: Gatling test
Background:
* url 'https://regres.in'
Scenario: Get api
Given path '/api/users/2'
When method GET
Then status 200
I looked at solutions provided in
Crashed with 'j.l.NullPointerException' when i try to run karate-gatling test reports
and also
https://github.com/intuit/karate/issues/404
But the solutions provided in that does not help either.
I am using Windows 10 with Eclipse Version: 2019-09 R (4.13.0).
I tried to run another project related feature file but that gave the same error so tried a simple test following a video tutorial - https://www.youtube.com/watch?v=RrRhndl-osY
Can someone kindly help please?
For the benefit of anyone else who faces this issue, the solution is to keep your pom.xml consistent with same version of Karate. My karate-gatling was 0.9.5.RC4 where as karate-apache was 0.9.4. When I made them both 0.9.5.RC4, I did not face these issues. Make sure pom.xml is consistent.
And if anyone runs into this kind of issue when compiling / running:
15:22:28.250 [main] ERROR io.gatling.compiler.ZincCompiler$ - one error found
15:22:28.252 [main] ERROR io.gatling.compiler.ZincCompiler$ - Compilation crashed
sbt.internal.inc.CompileFailed: null
at sbt.internal.inc.AnalyzingCompiler.call(AnalyzingCompiler.scala:242)
at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:111)
at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:90)
at sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$3(MixedAnalyzingCompiler.scala:82)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at sbt.internal.inc.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:133)
at sbt.internal.inc.MixedAnalyzingCompiler.compileScala$1(MixedAnalyzingCompiler.scala:73)
at sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:116)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.Incremental$.doCompile(Incremental.scala:106)
at sbt.internal.inc.Incremental$.$anonfun$compile$4(Incremental.scala:87)
at sbt.internal.inc.IncrementalCommon.recompileClasses(IncrementalCommon.scala:116)
at sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:63)
at sbt.internal.inc.Incremental$.$anonfun$compile$3(Incremental.scala:89)
at sbt.internal.inc.Incremental$.manageClassfiles(Incremental.scala:134)
at sbt.internal.inc.Incremental$.compile(Incremental.scala:80)
at sbt.internal.inc.IncrementalCompile$.apply(Compile.scala:67)
at sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:311)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:269)
at sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:159)
at sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:238)
at sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:69)
at io.gatling.compiler.ZincCompiler$.doCompile(ZincCompiler.scala:210)
at io.gatling.compiler.ZincCompiler$.delayedEndpoint$io$gatling$compiler$ZincCompiler$1(ZincCompiler.scala:215)
at io.gatling.compiler.ZincCompiler$delayedInit$body.apply(ZincCompiler.scala:39)
at scala.Function0.apply$mcV$sp(Function0.scala:39)
at scala.Function0.apply$mcV$sp$(Function0.scala:39)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:17)
at scala.App.$anonfun$main$1$adapted(App.scala:80)
at scala.collection.immutable.List.foreach(List.scala:392)
at scala.App.main(App.scala:80)
at scala.App.main$(App.scala:78)
at io.gatling.compiler.ZincCompiler$.main(ZincCompiler.scala:39)
at io.gatling.compiler.ZincCompiler.main(ZincCompiler.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at io.gatling.mojo.MainWithArgsInFile.runMain(MainWithArgsInFile.java:50)
at io.gatling.mojo.MainWithArgsInFile.main(MainWithArgsInFile.java:33)
This is likely to be because on Windows, the Java bin folder is not added to the System PATH. See the below thread for more details.
https://github.com/intuit/karate/issues/404#issuecomment-417630286
I'm stuck on deploying a war to a remote Jetty 9.
On the app-server side I've deployed the cargo-jetty-7-and-onwards-deployer (version 1.4.9). This component seems to be running correctly and responds with (as expected on a get request):
HTTP ERROR 400
Problem accessing /cargo-jetty-deployer/. Reason:
Command / is unknown Powered by Jetty://
To deploy I'm using the cargo-maven2-plugin (version 1.4.9) with this configuration:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>${cargo.plugin.version}</version>
<configuration>
<container>
<containerId>jetty9x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.servlet.port>80</cargo.servlet.port>
<cargo.hostname>ipgoeshere</cargo.hostname>
<cargo.protocol>http</cargo.protocol>
</properties>
</configuration>
<deployables>
<deployable>
<groupId>se.dn.nav</groupId>
<artifactId>nav-api</artifactId>
<type>war</type>
<properties>
<context>/api</context>
</properties>
</deployable>
</deployables>
</configuration>
</plugin>
When running: mvn cargo:deploy
this results in the following error message:
[ERROR] Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy (default-cli) on project nav-api: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy failed: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]: Response when calling http://ip:80/cargo-jetty-deployer/deploy?path=/api was: Error - Unexpected error when trying to start the webapp -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy (default-cli) on project nav-api: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy failed: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
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:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy failed: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.codehaus.cargo.container.ContainerException: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]
at org.codehaus.cargo.container.jetty.JettyRemoteDeployer.deploy(JettyRemoteDeployer.java:126)
at org.codehaus.cargo.maven2.DeployerDeployMojo.performDeployerActionOnSingleDeployable(DeployerDeployMojo.java:56)
at org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOnAllDeployables(AbstractDeployerMojo.java:166)
at org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(AbstractDeployerMojo.java:97)
at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:432)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
... 20 more
Caused by: org.codehaus.cargo.container.ContainerException: Response when calling http://ip:80/cargo-jetty-deployer/deploy?path=/api was: Error - Unexpected error when trying to start the webapp
at org.codehaus.cargo.container.jetty.JettyRemoteDeployer.deploy(JettyRemoteDeployer.java:119)
... 25 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
And after this the build and deployment fails.
I've checked the logs on the Jetty, I've also upped the logging level to DEBUG, but there's no indication what is going wrong on the server side.
Does anyone have a clue what I'm doing wrong?
Is there any way I can get a better error message to indicate whats going wrong?
Any help would be GREATLY appreciated! :)
P.s.
I've removed the ip int the log.
P.s.s.
The war I'm deploying is previously tested and runs fine on Jetty.
Seems like cargo-jetty-7-and-onwards-deployer is not compatible with Jetty 9+ (there were some lifecycle changes in Jetty 9 that cargo is likely not aware of)
Do this (to find out) ...
Start jetty with the following extra command line
java -jar /opt/jetty/start.jar -Dorg.LEVEL=DEBUG -Djetty.dump.start=true
Check the logs, there should be tons more information, including a server state dump.
If cargo-jetty-deployer is either not present or not labeled as STARTED then the deployer webapp itself failed to start.
If you feel like it, update your question with the dump and/or relevant webapp startup error logging events (not the entire log, as that is just far to noisy)
What worked for me is setting the config.home system property to the parent directory of the webapps directory of Jetty.
The deployer will copy the uploaded war to the webapps directory and let Jetty deploy it automatically.
If config.home is set then the deployer will use ${config.home}/webapps, if not then it will use ${jetty.home}/webapps as the target directory for the war file. For me the webapps directory is configured to be ${jetty.base}/webapps which is something different than ${jetty.home}/webapps. Setting ${config.home} equal to ${jetty.base} solved the issue.
I found net.sf.json-lib in the central repository. Copy-pasted the dependency (with version 2.3), and then when I build I get this error:
[INFO] Unable to find resource 'net.sf.json-lib:json-lib:jar:2.2.3' in repository central (http://repo1.maven.org/maven2)
[ERROR] BUILD ERROR
[INFO] ---------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) net.sf.json-lib:json-lib:jar:2.3
Try downloading the file manually from the project website.
I tried using version 2.2.3, but I'm getting the same error. Why am I getting this error? I can override it by installing it locally, but I want to understand what the problem is.
Edit - I deleted the package from my local repository, and tried again, this time getting a checksum error. I guess I should file a bug report with json-lib.
[WARNING] *** CHECKSUM FAILED - Error retrieving checksum file for net/sf/json-lib/json-lib/2.3/json
-lib-2.3.pom - IGNORING
Looking at the maven-central repo, you need to specify a classifier for this dependency.
Either jdk13 or jdk15, like this:
<dependency>
<groupId>net.sf.json-lib</groupId>
<artifactId>json-lib</artifactId>
<version>2.4</version>
<classifier>jdk15</classifier>
</dependency>
For gradle as sample
compile 'net.sf.json-lib:json-lib:2.4:jdk15'
OR
compile group: 'net.sf.json-lib', name: 'json-lib', version: '2.4', classifier: 'jdk15'
I searched for more classifier's could not find anything other than jdk15 (don't go looking or jdk16 or jdk17)
Barring khimarbaise's comment about trustworthiness, you can install it locally using maven install:
http://maven.apache.org/plugins/maven-install-plugin/examples/specific-local-repo.html
mvn install:install-file -Dfile=path-to-your-artifact-jar
-DgroupId=your.groupId
-DartifactId=your-artifactId
-Dversion=version
-Dpackaging=jar
-DlocalRepositoryPath=path-to-specific-local-repo
For ivy users, after trying many different iterations to configure my ivy.xml to properly find this dependency, this finally worked for me:
<dependency org="net.sf.json-lib" name="json-lib" rev="2.4">
<artifact name="json-lib" url="http://repo1.maven.org/maven2/net/sf/json-lib/json-lib/2.4/json-lib-2.4-jdk15.jar"/>
</dependency>
Update
As of Hudson Findbugs plug-in version 4.3 this is no longer an issue
End Update
As an example of my problem, I'm trying to build the following project http://www.sonatype.com/books/mvnex-book/reference/multimodule.html
I added the following to simple-parent/pom.xml
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.3</version>
<configuration>
<findbugsXmlOutput>true</findbugsXmlOutput>
<findbugsXmlWithMessages>true</findbugsXmlWithMessages>
<xmlOutput>true</xmlOutput>
</configuration>
</plugin>
</plugins>
</reporting>
And the following to simple-weather/pom.xml and simple-webapp/pom.xml
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
</plugin>
</plugins>
</reporting>
I inserted the following horrible equals method into one of the classes to have FindBugs generate some issues (as there is no error on 0 bugs):
public boolean equals(Object o) { return true; }
I'm using Hudson with a maven2 style project. The job is aimed at the simple-parent pom with the goals
clean site
I get the following exception:
[INFO] Generating "FindBugs Report" report.
[java] Warnings generated: 2
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot inherit from final class
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.VerifyError: Cannot inherit from final class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch2(RemoteClassLoader.java:370)
at sun.reflect.GeneratedMethodAccessor594.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
at hudson.remoting.Request$2.run(Request.java:270)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)
Version info:
Maven 2.2.1
Java 1.5.0_22
Hudson 1.341 (also found on 1.339) running inside JBoss 4.0.5.GA (same error on 4.2.2.GA and 5.1.0.GA)
Maven FindBugs plugin 2.3
Hudson FindBugs plugin 4.1
Any ideas on how to fix this?
According to the FindBugs FAQ, this problem occurs when the wrong version of Apache BCEL is being used (see Q2: When I click the "Find Bugs!" button, I get a NoSuchMethodError or VerifyError). In your case, I suspect that the maven-findbugs-plugin is getting the BCEL library from JBoss because of some obscure classloading issue. There are some very similar bugs in Hudson's Jira, e.g. HUDSON-5134 (the hudson findbugs plugin is also affected).
My understanding is that this problem has been introduced recently (in v1.338) and, even if there is a workaround, it is an Hudson bug (it is a regression, it's not a problem with JBoss).
Now, you have IMO two solutions:
Use a version of Hudson anterior to v1.338 (the regression was reported for this version) but using an old version and sticking with it is certainly not really a viable solution.
Remove or replace the bcel.jar of JBoss (in server/SERVERNAME/lib) with the version used by the maven-findbugs-plugin (see dependencies). I'm not able to say how this will affect JBoss exactly (If you remove it, it seems that you will loose the ability to run JBoss in debug-mode but I can't say if everything will work fine if you replace it).
Whatever you'll do, please create a new Jira issue (http://issues.hudson-ci.org/) as this is a regression in Hudson. They have marked HUDSON-5134 as "Won't fix" because there is a workaround but I don't think that messing with JBoss libraries is a good solution (I'm repeating myself but this is a Hudson bug). So, insisting and letting Hudson developers know that other users are affected by this problem will help all the entire community (at least, I hope so).
The other answers provided are better, but one alternative to add: use Ant or batch file to create a separate build step that doesn't care that the FindBugs step failed. The Hudson plug-in can still be used to display the results.
As Pascal points out, there is a similar bug filed - HUDSON-5134 - and that bug indicates the behavior started with Hudson release 1.338. Since Hudson releases once a week, it can be difficult to pin down which version introduced a bug. I notice there was a classloader related change released with Hudson version 1.337 (HUDSON-5048), and I suspect that is causing the problem here, but I don't have direct evidence of that.
But that likely means you need to roll back to 1.337 or earlier to avoid this problem.