I am new in apache Cassandra.
I have installed Apache Cassandra 1.2.5 and Apache Maven. Right now I just want to run the hector-examples posted by zznate in github.com. I am using Mac iOS.
I cloned the hector-examples folder into my local folder, and used the command
mvn -e exec:java -Dexec.mainClass="com.riptano.cassandra.hector.example.InsertSingleColumn"
Built failure.
Is there any steps that I am missing? Thank you very much.
ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.1:java (default-cli) on project hector-examples: An exception occured while executing the Java class. com.riptano.cassandra.hector.example.InsertSingleColumn -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.1:java (default-cli) on project hector-examples: An exception occured while executing the Java class. com.riptano.cassandra.hector.example.InsertSingleColumn
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
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:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)...
Caused by: java.lang.ClassNotFoundException: com.riptano.cassandra.hector.example.InsertSingleColumn
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:283)
at java.lang.Thread.run(Thread.java:680)
I think this has something to do with Maven build.
Can you try these steps:
mvn clean install
mvn -e exec:java -Dexec.mainClass="com.riptano.cassandra.hector.example.InsertSingleColumn"
If you are willing to look for other options, astyanax is an excellent choice for querying/ working with cassandra cluster. You can look for examples here.
Just add the maven dependency or jars in your project and it should be pretty straightforward from there on.
Another option is Datastax java driver. If you've worked with SQL, cassandra has similar querying language called CQL which is amazingly simple and good to use.
Examples available here.
And this is how you insert dataINSERT INTO users
(user_name, password)
VALUES ('jsmith', 'ch#ngem3a');
Related
My jenkins builds just started to fail with this message:
[INFO] --- sonar-maven-plugin:2.7:sonar (default-cli) # cividas-core-web ---
[INFO] artifact com.ontimize:ontimize-core: checking for updates from central
[INFO] artifact com.ontimize:ontimize-core: checking for updates from imatia-local
[INFO] artifact com.ontimize:ontimize-core: checking for updates from snapshots
[INFO] User cache: /var/lib/jenkins/.sonar/cache
[INFO] SonarQube version: null
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.773s
[INFO] Finished at: Thu Oct 22 19:49:04 CEST 2015
[INFO] Final Memory: 13M/193M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.7:sonar (default-cli) on project cividas-core-web: null: MojoExecutionException: NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.7:sonar (default-cli) on project cividas-core-web: null
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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.MojoExecutionException
at org.codehaus.mojo.sonar.bootstrap.ExceptionHandling.handle(ExceptionHandling.java:41)
at org.codehaus.mojo.sonar.bootstrap.RunnerBootstrapper.execute(RunnerBootstrapper.java:107)
at org.codehaus.mojo.sonar.SonarMojo.execute(SonarMojo.java:141)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: java.lang.NullPointerException
at org.apache.maven.artifact.versioning.ComparableVersion.parseVersion(ComparableVersion.java:354)
at org.apache.maven.artifact.versioning.ComparableVersion.<init>(ComparableVersion.java:345)
at org.apache.maven.artifact.versioning.DefaultArtifactVersion.parseVersion(DefaultArtifactVersion.java:110)
at org.apache.maven.artifact.versioning.DefaultArtifactVersion.<init>(DefaultArtifactVersion.java:46)
at org.codehaus.mojo.sonar.bootstrap.RunnerBootstrapper.isVersionPriorTo5Dot2(RunnerBootstrapper.java:192)
at org.codehaus.mojo.sonar.bootstrap.RunnerBootstrapper.execute(RunnerBootstrapper.java:84)
... 22 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[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/MojoExecutionException
Sonar analysis completed: FAILURE
What is this all about?
Solved by downgrading the automatically picked latest (2.7) version to an older one (2.4) by adding this code to the plugins section of my pom.xml
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>2.4</version>
</plugin>
For those interested in "why?", I've done some more digging and what seems to be happening is this:
RunnerBootstrapper attempts to check whether a version is 5.2+:
First, serverVersion is retrieved from a launcher created in EmbeddedRunner,
using IsolatedLauncher creating a proxy of implementation class BatchIsolatedLauncher
which attempts to read a resource file sq-version.txt containing the version.
This sq-version.txt file is located in org.codehaus.sonar:sonar-plugin-api, but this dependency is not included (even transitively) in the sonar-maven-plugin. All it references sonar-wise is org.sonarsource.sonar-runner:sonar-runner-api.
They seem to have changed the location and name of the version txt file but not updated all code. You might get away with manually adding an sq-version.txt with content 5.2 (no newline) to the plugin classpath (possibly by updating the plugin jar), or add a dependency on sonar-plugin-api, but these are hacks.
The sonar-maven-plugin 2.6 uses sonar-runner 2.4, which is very different from 2.5 that sonar-maven-plugin 2.7 uses (the groupId for sonar-runner has changed domains from org.codehaus.sonar.runner to org.sonarsource.sonar-runner), so it's best to stick to the v2.6 plugin until they have smoothed out the transition and released a few more versions.
The way SonarQube server version is passed to maven-sonar-plugin has changed in v2.7, along with other things, since it uses now sonar-runner 2.5.
There is indeed a bug when using it with SonarQube instances < 4.3, for which I opened the ticket: https://jira.sonarsource.com/browse/MSONAR-131
Note that SQs < 4.5 (current LTS) are no longer actively supported and there is no guarantee that sonar-maven-plugin won't be incompatible with them in other ways due to the new interface exposed by sonar-runner 2.5.
For these cases, it is probably best to lock the maven plugin version to 2.6, as already suggested.
We had the same problem at work today, we automatically use the latest version for maven and sonar plugins. It wasn't easy to find the problem at first.
The answer elcodedocle has given is correct, but i would like to add for those that use maven with sonar in an automated fashion that this is a solution aswell:
org.codehaus.mojo:sonar-maven-plugin:2.6:sonar
This way it runs on the older version 2.6 and i can confirm that it works.
There is probably a bug in 2.7 and i hope it gets fixed soon. This was our error:
[ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven plugin:2.7:sonar (default-cli) on project (projectName): Unable to determine structure of project. Probably you use Maven Advanced Reactor Options with a broken tree of modules. "(projectName)" is orphan -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[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/MojoExecutionException
EDIT:
Take a look at this post for some more information: Jenkins Sonar plugin suddenly stops working
Here is explained that the new version, 2.7, of the plugin is no longer compatible with java 6 projects. You can also find an explanation about how to fix it in Jenkins if you are not familiar with it. (my explanation was a bit short)
This is a hint:
[INFO] SonarQube version: null
Later in the code, Maven tries to parse this version number and fails. The source code is here: https://github.com/mojohaus/sonar-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/sonar/bootstrap/RunnerBootstrapper.java
From the source of the SonarQube runner, this is backed by a properties instance. So maybe the code couldn't access the server or the server isn't sending this data back. Hard to tell.
What I can see is that the code changed in 2.5. That's probably why 2.4 still works. See here how to nail down the versions: Jenkins Sonar plugin suddenly stops working
Discover the appropriate plugin version for you running sonar installation.
E.g.
mvn org.codehaus.mojo:sonar-maven-plugin:2.6:sonar
This plugin version will not work against the latest sonar release but will work fine against a 4.1.2.
I am trying to use a library that is available on GitHub (MailChimp API Wrapper for Java). Unfortunately, they do not distribute the library classpath .jar or javadocs as a direct download.
Attempting to build the classpath .jar myself, I downloaded the .zip file which contained a Netbeans project and opened the Netbeans project (which is a Maven project... I'm not too familiar with Maven). I tried to clean & build the project (hoping for it to spit out a nice .jar which I can import into my other project).
But, the clean & build failed with this message:
Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test (default-test) on project ecwid-mailchimp: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? -> [Help 1]
To see the full stack trace of the errors, re-run Maven with the -e switch.
Re-run Maven using the -X switch to enable full debug logging.
For more information about the errors and possible solutions, please read the following articles:
[Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
The website it directs you to says:
This error is reported in case the execution of a plugin failed due to some unforeseen event. For example, uncatched runtime exceptions caused by the plugin will raise this error. You should report this problem to the maintainer of the plugin.
Now, I'd love to believe I've done everything correctly and that this is, indeed, a problem with the build. But, before I go sending a nastygram email to the API creator, I'd like to ensure that the error is not on my end.
So, the question is thus: If you had a Netbeans Maven project that you wanted to compile to create a library classpath .jar to use in another project, what would you do? And am I doing it correctly?
EDIT:
Building the project with -e yielded this as a result:
Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test (default-test) on project ecwid-mailchimp: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test (default-test) on project ecwid-mailchimp: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
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:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.RuntimeException: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:245)
at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:282)
at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:116)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:695)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(AbstractSurefireMojo.java:666)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:624)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:587)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Re-run Maven using the -X switch to enable full debug logging.
For more information about the errors and possible solutions, please read the following articles:
[Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
Soo.... that's a thing.
If you just want jar and don't want to care about test execution (where it dies) you can invoke
mvn clean install -DskipTests
to skip surefire plugin's execution and to get the jar
and then in your project add this artifact as dependency (assuming it is maven project)
<dependency>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
</dependency>
if you want to see what is going wrong, I doubt it is the jvm crashed most likely related to OutOfMemory, I would increase maven's memory by setting higher heap space in MAVEN_OPTS and increasing surefire's plugin jvm's heap if it is a fork
I'm using SVN, Maven 3.0.3 on the latest version of Jenkins and the Maven Release plugin. I'm trying to use the Maven release plugin (through Jenkins) do a dry run and so am executing the options …
Executing Maven: -B -f /scratch/jenkins/workspace/myproject/myproject/pom.xml -DdevelopmentVersion=53.0.0-SNAPSHOT -DreleaseVersion=52.0.0 -Dusername=***** -Dpassword=********* -DskipTests -P prod -Dresume=false -DdryRun=true release:prepare
But the dry run is dying with the error below …
[JENKINS] Archiving /scratch/jenkins/workspace/myproject/myproject/pom.xml to /home/evotext/hudson_home/jobs/myproject/modules/org.mainco.subco$myproject/builds/2013-11-18_16-09-14/archive/org.mainco.subco/myproject/52.0.0/myproject-52.0.0.pom
Waiting for Jenkins to finish collecting data
mavenExecutionResult exceptions not empty
message : Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on project myproject: You don't have a SNAPSHOT project in the reactor projects list.
cause : You don't have a SNAPSHOT project in the reactor projects list.
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on project myproject: You don't have a SNAPSHOT project in the reactor projects list.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:117)
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.launchStandard(Launcher.java:329)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:178)
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 hudson.maven.Maven3Builder.call(Maven3Builder.java:129)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:67)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.apache.maven.plugin.MojoFailureException: You don't have a SNAPSHOT project in the reactor projects list.
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:219)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 30 more
Caused by: org.apache.maven.shared.release.ReleaseFailureException: You don't have a SNAPSHOT project in the reactor projects list.
at org.apache.maven.shared.release.phase.CheckPomPhase.execute(CheckPomPhase.java:111)
at org.apache.maven.shared.release.phase.CheckPomPhase.simulate(CheckPomPhase.java:123)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211)
... 33 more
My SVN checkout method is set to "Always checkout a fresh copy" and I have a snapshot version in question in my snapshot repository, but not in my release repository. Is there a way I can get the "reactor projects list" to look at my snapshot repo?
Edit: I'm including the snippet of my pom where the project gets its version -- it inherits it from a parent
<parent>
<artifactId>subco</artifactId>
<groupId>org.mainco.subco</groupId>
<version>52.0.0</version>
</parent>
You're trying to release an artifact that's not a snapshot. That means your artifact's version number is something like 3.0.3. That version number implies its already been released. You can't release a release. There would be no changes in between and therefore no point.
You're only supposed to release SNAPSHOT versions. That means your version number would be like 3.0.3-SNAPSHOT.
Jenkins workspace is not cleanup or you have FINAL version inside pom.xml. Jenkins has check-out strategy for cleaning up workspace.
More: Maven release plugin - SNAPSHOT project needed
Check-out Strategy options:
Emulate clean checkout by first deleting unversioned files/ignored files, as well as files/directories ignored by svn:ignore, then execute svn update.
Always check out fresh copy
Use svn update as much possible, with svn revert before update
Bump Up your Project POM file for from the previously built code base to a new version.
1.0.1-SNAPSHOT<version>1.0.1-SNAPSHOT</version>
Changing the check-out strategy to "Emulate clean checkout by first deleting unversioned files/ignored files, then svn update" did the trick for me.
Context
I'm currently having an issue with sonarqube 3.7 being run by maven via jenkins
The project is setup as a maven multi-module project and jenkins is running sonar (via maven) using the following param: "-pl "
I have updated "sonar" 3.6 to "sonarqube" 3.7 and also "sonar-maven-plugin" to 3.7
Problem
Since the update I see the following error in jenkins (1.529):
[ERROR] Failed to execute goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar (default-cli) on project xxxxx: Execution default-cli of goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar failed: Unable to execute Sonar: Maven session does not declare a top level project -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar (default-cli) on project xxxxx: Execution default-cli of goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar failed: Unable to execute Sonar
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
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:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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:616)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar failed: Unable to execute Sonar
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
at org.sonar.runner.api.Runner.execute(Runner.java:90)
at org.sonar.maven.SonarMojo.execute(SonarMojo.java:172)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Caused by: java.lang.IllegalStateException: Maven session does not declare a top level project
at org.sonar.plugins.maven.MavenProjectBootstrapper.bootstrap(MavenProjectBootstrapper.java:53)
at org.sonar.batch.scan.ProjectScanContainer.projectBootstrap(ProjectScanContainer.java:104)
at org.sonar.batch.scan.ProjectScanContainer.doBeforeStart(ProjectScanContainer.java:82)
at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:86)
at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:73)
at org.sonar.batch.scan.ScanTask.scan(ScanTask.java:57)
at org.sonar.batch.scan.ScanTask.execute(ScanTask.java:45)
at org.sonar.batch.bootstrap.TaskContainer.doAfterStart(TaskContainer.java:82)
at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:88)
at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:73)
at org.sonar.batch.bootstrap.BootstrapContainer.executeTask(BootstrapContainer.java:156)
at org.sonar.batch.bootstrap.BootstrapContainer.doAfterStart(BootstrapContainer.java:144)
at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:88)
at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:73)
at org.sonar.batch.bootstrapper.Batch.startBatch(Batch.java:92)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:74)
at org.sonar.runner.batch.IsolatedLauncher.execute(IsolatedLauncher.java:45)
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:616)
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:87)
... 28 more
Expected behavior
sonar should check the code as it did with the previous version
Alternative solution
If I do not use the -pl param (it works only if I delete the project in sonarqube)
But I would still like to only run sonar on a specific module.
You are running into what a lot of us heavy SonarQube users find on a regular basis: any off-nominal techniques to invoke SonarQube will break during some eventual upgrade. We're so used to it at work that we simply bake in the time to remediate upgrade issues into the cost of a SonarQube upgrade.
I don't doubt that -pl worked in the past. But as SonarQube continues to work against many languages, it will shed its roots as a Java- and Maven-only continuous inspection tool.
SonarQube is happiest when you're invoking it as a plain-jane mvn sonar:sonar. You should specify additional SonarQube configuration in your multimodule parent POM, because that's the only guaranteed means by which an altered configuration will be honored, now and in the future.
If you just want to run SonarQube against one module, set sonar.includedModules to include only the multimodule parent as well as the target module. So if your multimodule parent's <artifactId> is foo-parent and your desired module is foo-module, you need to set the following property in foo-parent's POM:
sonar.includedModules=foo-parent,foo-module
I had the same issue when I'm trying to run sonar through command like :- sonar:sonar -pl moduleA where it was looking for parent module, So I've tried this & it worked with :- sonar:sonar -pl .,moduleA. This will build only one specific project in multi-module maven project & as we've specified "." it would build parent pom which resolved the issue.
sonar.includedModules are deprecated since 4.3
https://docs.sonarqube.org/display/SONARQUBE53/Release+4.3+Upgrade+Notes
The sonar.skippedModules and sonar.includedModules properties are deprecated. They should be replaced by standards Maven advanced reactor options. For example, let's say that you have the following multi-module project:
org.mycompany:my-project
- moduleA (org.mycompany:module-A)
- moduleB (org.mycompany:module-B)
- moduleC (org.mycompany:module-C)
Then
mvn sonar:sonar -Dsonar.skippedModules=module-B
should be replaced (since Maven 3.2.1) by
mvn sonar:sonar -pl !moduleB
I know this is a bit old question, but what helped me on this case of using the -pl option was to use the opposite logic. Instead of passing the modules you want to execute the analysis you should pass the modules you don't want to analyze instead. For example, if you have 4 modules and just want to analyze the third one, you -pl you look like this:
-pl !module1,!module2,!module4
SonarQube doesn't support the Maven '-pl' option, see https://jira.sonarsource.com/browse/SONAR-1742
I'm trying to create an archetype from an existing multi module maven project. For this, I change the directory to the root directory (where the root pom.xml is in) and issue a "mvn archetype:create-from-project". The build doesn't finish and I get the following error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.2:create-from-project (default-cli) on project siaci-d: charsetName -> [Help 1]
Running again with the -e and -X flags I can see the following stack trace:
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.2:create-from-project (default-cli) on project siaci-d: charsetName
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoFailureException: charsetName
at org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:285)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
I checked the maven-archetype-plugin documentation and didn't find any reference to a charsetName attribute. So, I'm a bit lost about how to fix this. I'm using maven 3.0.4 with java 1.6.0_25 on a Ubuntu box. Any advice?
Any idea of what is going wrong here?
You posted this question some time ago, however this answer may help others.
I had the same problem in a project. This error happens when you have a file in your project that contains characters in a different encondig. A solution to this problem is replacing this characters — if it's not many, generate the archetype, revert the characters to the original and at last, change to the right enconding at the archetype metadata file.
Another option is to change the default enconding UTF-8 in the archetype generation, like this:
mvn archetype:create-from-project -Darchetype.properties=../archetype.properties
For more information, follow this guides:
http://maven.apache.org/archetype/maven-archetype-plugin/create-from-project-mojo.html#defaultEncoding
http://maven.apache.org/archetype/maven-archetype-plugin/examples/create-with-property-file.html
I was dealing with the same error then I found out what was messing up the archetype creation...
First, I chose the encoding ISO-8859-1 by inserting the properties below on pom.xml:
<properties>
<project.build.sourceEncoding>ISO-8859-1</project.build.sourceEncoding>
<project.reporting.outputEncoding>${project.build.sourceEncoding}</project.reporting.outputEncoding>
<project.resources.sourceEncoding>${project.build.sourceEncoding}</project.resources.sourceEncoding>
</properties>
Afterwards, I inserted the archetype-plugin with all configurations below at the build section of pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-archetype-plugin</artifactId>
<version>2.2</version>
<configuration>
<defaultEncoding>${project.build.sourceEncoding}</defaultEncoding>
<encoding>${project.build.sourceEncoding}</encoding>
<archetypeArtifactId>archetype-wsjpa</archetypeArtifactId>
<archetypeGroupId>br.com.example</archetypeGroupId>
<archetypeVersion>1.0</archetypeVersion>
<archetypeFilteredExtentions>java,xml</archetypeFilteredExtentions>
</configuration>
</plugin>
By doing so, you should provide all archetype generation configuration in your own pom.xml instead of writing a property file (archetype.properties) to declare this configuration.
And finally, I ran maven with mvn clean install then mvn archetype:create-from-project -e -X
Even so, you still may notice some encoding errors like the one reported in this post, even if you have updated your pom.xml as shown above... If you're still having the same error after setting the correct encoding for your project, try to figure out which project file still contains invalid characters.
To find the troublemaker file you should observe the debug lines that Maven shows on the console like this one: "[DEBUG] InputFileName:src\main\resources\META-INF\persistence.xml" and check which project files has been written to the folder ${basedir}\target\generated-sources\archetype\src\main\resources\archetype-resources.
When encoding errors occurs during archetype creation, the aforementioned folder doesn't match the original project contents and it happens because Maven couldn't copy some resources due to invalid or incompatible characters which is not contained in the property specified charset.