I have maven project that fails when release:perform is called, though release;prepare works as expected.
I have found the bug report (below) which certainly seems to resemble the issue I have but not entirely sure I understand the problem:
MRELEASE516
The last few lines of output I get:
[INFO] Executing: cmd.exe /X /C "p4 -d E:\hudson\jobs\myHudsonJob\workspace\target\checkout -p 1.1.1.1:1111: client -d myProjectWorkspace-MavenSCM-E:\hudson\jobs\myHudsonJob\workspace\target\checkout"
[INFO] Executing goals 'deploy'...
[WARNING] Base directory is a file. Using base directory as POM location.
[WARNING] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance.
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error executing Maven.
Working directory "E:\hudson\jobs\myHudsonJob\workspace\target\checkout\workspace" does not exist!
From reading the bug report the possible cause of the error is related to my modules' structure, I've tried to outline it below:
/workspace
|
|+ pom.xml (root pom whose parent is the build pom,
| calling release:perform on this pom)
| [Modules: moduleA and moduleB]
|
|- moduleA
|+ pom.xml (parent is also build pom)
|+ build/pom.xml (the build pom - no custom parent)
|- moduleB
|+ pom.xml (parent is build pom)
It seems that the root pom should be in some common directory inside 'workspace' from the error but tried that and doesn't work, nor make sense as to why I need it.
What does the warning Base directory is a file want me to do instead?! It then figures that the base directory is workspace which then means the working directory is not found...any ideas?
Thanks in advance.
EDIT:
Having checked the SCM configuration it all looks ok to me...in each module and the root pom I have:
<scm>
<connection>
scm:perforce:1.1.1.1:1111://rootToDirectoryContainingRelevantPom
</connection>
<developerConnection>
scm:perforce:1.1.1.1:1111://rootToDirectoryContainingRelevantPom
</developerConnection>
</scm>
EDIT 2:
Maybe I have hit MRELEASE-261?
I got this working by using a newer version of the release plugin. The Maven super pom has a dependency on v2.0 of the release plugin defined. If you don't override this then that the version will be used.
You can specify a newer version when you run the plugin
mvn org.apache.maven.plugins:maven-release-plugin:2.2.1:perform
Or you can override the dependency version in your pom
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.2.1</version>
</plugin>
I'm not sure you're facing MRELEASE-516 (which is about release:prepare). However, I wonder if you have correct <scm> informations in each POM. Can you confirm this?
Working directory "E:\hudson\jobs\myHudsonJob\workspace\target\checkout\workspace" does not exist!
I just saw the above line in your log. It looks like you have some screwy path setting somewhere. Do you overwrite the Workspace somewhere? Check your configuration and try to eliminate as much as possible the optional settings.
In my case the same symptoms turned out to be a result of a bug in maven-release-plugin:2.2.1. See MRELEASE-705.
So to get rid of the error, I've got to put this into the parent pom:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
</plugin>
</plugins>
</build>
This error was occurring for us
Working directory E:\Data\myproject\target\checkout does not exist!
We're in the middle of a large transition of server tools and maven's release:prepare appeared to be failing silently, claiming the tags and version number changes had been pushed without error. However, after some research, these things had only been committed to the local git repository, not pushed - even though the release:prepare was executing commands to perform a push but never reported a failure -- even with the maven -e and -X command line parameters.
We're using Maven 3.3.9, maven release plugin 2.5.3, and git client 2.9.2.
Our end solution was to add a (or correct the, as your case may be) definition in maven's ~\.m2\settings.xml file for our git server (origin master) including username and password with privileges for pushing tags (as well as pushing to master). The id in the server definition for the git server needed to be the git server's hostname:
<servers>
<server>
<id>git-server</id>
<username>dan</username>
<password>changeit</password>
</server>
<servers>
With this update, the tag completes on the server and the checkout occurred successfully.
Related
I am trying to use flyway from maven and I have pom that looks like this with regard to flyway:
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>3.1</version>
<inherited>false</inherited>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>migrate</goal>
</goals>
<configuration>
<user>jrm</user>
<password></password>
<driver>com.mysql.jdbc.Driver</driver>
<url>jdbc:mysql://localhost/fooDB?createDatabaseIfNotExist=true</url>
<table>version_history</table>
<locations>
<location>
filesystem:../../scripts/entitlement/db/cd
</location>
</locations>
Note that the jrm user requires no password but I have gotten the same result with users that have a non-null password. On Windows I can use MySQL command line client to log into the db. My impression of this message is that it indicates something is wrong with the authentication; using flyway version 4.0.3 it says to check user, password and url.
I believe this might be Windows specific problem. Note that I have add the MySQL bin to the path environment variable. I note that I am not prompted for a password when I try mysql -u root, I just get access denied unless I use mysql -u root -p and I have some reason to believe that I needed a user that therefore had a null password.
EDIT: I am using mvn flyway:migrate
The answers given by wemu are completely correct: it was necessary, as the pom is currently written, to do mvn compile rather than flyway:migrate. Moreover, wemu's subsequent suggestion about moving the configuration should make it possible to invoke Flyway directly which is probably the correct way to do things. I guess the error messages from the Flyway plugin are completely accurate: it did not see the authorization/db access configuration but I did not know enough about Maven to understand why and spent significant time thinking the info was wrong not merely unavailable to the plugin.
I have small gear with tomcat cartridge. When I try to execute war that that generate images with Java3D I get following exception:
Caused by: java.lang.ClassNotFoundException: javax.media.j3d.Node
As a first think I tried to add Java3D at classpath, I have added to my pom.xml:
<dependency>
<groupId>java3d</groupId>
<artifactId>j3d-core-utils</artifactId>
<version>1.3.1</version>
<scope>compile</scope>
</dependency>
This added to final war following artifacts:
[INFO] +- java3d:j3d-core-utils:jar:1.3.1:compile
[INFO] | +- java3d:vecmath:jar:1.3.1:compile
[INFO] | \- java3d:j3d-core:jar:1.3.1:compile
When I deployd adjusted war following exception raised:
Caused by: java.lang.UnsatisfiedLinkError: no J3D in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)
As far as I understand exception, it says that there are no native Java3D libraries at java.library.path. So I installed Java3D from suggested link, I also updated j3dcore.jar, j3dutils.jar and vecmath.jar. Also catalina.sh was updated:
export LD_LIBRARY_PATH=/var/lib/openshift/<my-application-id>/app-root/data/j3d-1_5_2-linux-amd64/lib/amd64
I suppose that there is no X11 server to work with, because of that Java3D have to run in headless mode. It could be set in catalina.sh like this:
JAVA_OPTS=${JAVA_OPTS}" -Djava.awt.headless=true"
Now it seems that all java3D classes and *.so libraries are found. Now there is another problem:
java.awt.HeadlessException
at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:64)
Problem is that Java3D class Canvas3D can't work in headless mode. Only way could be to connect to some X11 server with screen. It could be done with export DISPLAY=:0.0
As far as I was able to test, it seems that there is no X11 server, providing screen to which could Java3D connect. Because of that it's not possible to run Java3D at OpenShift platform with tomcat cartridge.
Thanks for your help.
Have you tried adding it to your pom.xml to get installed via maven? Or add the .jar file to your project manually... http://mvnrepository.com/artifact/java3d/j3d-core-utils/1.3.1
You might require more than just the core package.
Since you are deploying a war file, and not using maven, i think you would need to download the jar files and embed them in your war file as libraries and use them.
You might also check out this article: https://www.openshift.com/kb/kb-e1087-how-to-include-libraries-jar-files-in-your-java-application-without-using-maven
It looks like there is also a .so file that you would need to include with something like -Djava.library.path
Here is the file with the jars & .so file on java.net http://download.java.net/media/java3d/builds/release/1.5.2/j3d-1_5_2-linux-amd64.zip
Speaking with the dev ops team, it does not seem that package is installed on the servers.
I have the following situation. I need to be able to run two programs launched by different batch files where each batch file invokes a java class with main() from the same jar. I would like each program to have its own log. However, the second program is an installer for the first, and therefore, I don't want to/can't easily specify -Dlogback.configurationFile=/path/to/config file as that location may not yet exist.
Logback documentation seems to provide a solution but I need an example of how to make it work:
Specifying the location of the default configuration file as a system
property
If you wish, you can specify the location of the default configuration
file with a system property named logback.configurationFile. The value
of this property can be a URL, a resource on the class path or a path
to a file external to the application.
java -Dlogback.configurationFile=/path/to/config.xml
chapters.configuration.MyApp1
Can anyone point me to an example where logback.configurationFile is defined as a resource on the classpath as opposed to the file system?
You can simply put a my-logback.xml in the root of one of your classpath entries and specify -Dlogback.configurationFile=my-logback.xml. Internally it will probably use ClassLoader#getResource(String name) to get the file - check the JavaDoc of this method for more information.
the answer to this question is in the supplied link:
https://logback.qos.ch/manual/configuration.html#configFileProperty
with the examples below:
The contents to include can be referenced as a file, as a resource, or as a URL.
As a file:
To include a file use the file attribute. You can use relative paths but note that the current directory is defined by the application and is not necessarily related to the path of the configuration file.
As a resource:
To include a resource, i.e a file found on the class path, use the resource attribute.
<include resource="includedConfig.xml"/>
As a URL:
To include the contents of a URL use the url attribute.
<include url="http://some.host.com/includedConfig.xml"/>
I have a slightly different solution than offering command line arguments.
My project is set up like so:
| foo
- src
- conf
- logback.xml
- main
- test
I wanted the logback.xml outside of the jar since I had the scanPeriod set for live reload. I figured since it should get picked up on the classpath, I'll add the path to the manifest.mf and it'll get picked up automatically.
Related parts of foo's pom.xml looks like this:
<plugins>
. . . Some plugins before
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/conf</outputDirectory>
<resources>
<resource>
<directory>src/conf</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.company.foo.main.Main</mainClass>
</manifest>
<manifestEntries>
<version>${project.version}</version>
<Class-Path>.</Class-Path>
<Class-Path>conf/</Class-Path>
</manifestEntries>
</archive>
</configuration>
</plugin>
. . . Some plugins after
</plugins>
Important things to take note of:
Maven Resources Plugin
Copies all files in src/conf to the standard compilation folder target/conf.
Maven Jar Plugin
Adds the conf folder to the MANIFEST.MF's classpath so that you don't need to specify the location on the command line.
All files in the conf folder will be added to the classpath, not just logback.xml
For the jar to run in this scenario, the conf folder must be placed alongside the jar. It will look like so:
path/to/jar
| foo.jar
| lib/
| conf/
| logback.xml
The MANIFEST.MF looks something like this:
Manifest-Version: 1.0
Built-By: $user
Class-Path: lib/x.jar lib/y.jar lib/z.jar conf/
version: 0.0.1-SNAPSHOT
Created-By: Apache Maven 3.5.2
Build-Jdk: 1.8.0_161
Main-Class: com.company.foo.main.Main
OK I went ahead and tried it out.
If the logback config file is local to the jar (in the same jar you're running in), this works:
System.setProperty("logback.configurationFile", "org/package/path/your.logback.xml");
works. If it's in the classpath 'anywhere'. Which is really weird since normally with a call to getResource you have to specify it with a preceding slash like:
YourClass.class.getResource("/org/package/path/your.logback.xml") so not sure why.
Other more exotic resource paths like specifying the exact jar also seem to not work. Weird.
I am writting a small Java application to connect to a HBase node. The ZooKeeper connection is successful, but later, I systematically get the following error (I have changed my IP address of course):
org.apache.hadoop.hbase.MasterNotRunningException 12.34.56.78:60000
Does anyone know what is happening and how to solve this issue?
Thanks!
Ok, solved that issue. Before someone commits suicide... -> the problem is caused by a mismatch between the HBase.jar versions available in the central maven repository (currently 0.90.xx) and those used by Cloudera's CDH3 installation package (0.89.xx).
The main issue is that Cloudera compiles its own Hbase.jar and these are not available from the central repository. But, Cloudera makes them available from:
<repositories>
<repository>
<id>cloudera</id>
<url>https://repository.cloudera.com/content/groups/public/</url>
</repository>
</repositories>
To find the HBase version you need for your application, open http://your.node.ip.address:60010. For CDH3Beta3, it is 0.89.20100924-28. Then, add it in your pom.xml as a dependency:
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase</artifactId>
<version>0.89.20100924-28</version>
</dependency>
Et voila!
I want to release a new version of my project using the Maven-Release-Plugin.
I get the following error, though:
[INFO] Tagging release with the label softsmithy-lib-v0.1...
[INFO] EXECUTING: /bin/sh -c cd /var/lib/hudson/jobs/SoftSmithy-Utility-Library-Release && hg tag --message '[maven-release-plugin] copy for tag softsmithy-lib-v0.1' softsmithy-lib-v0.1
[ERROR]
EXECUTION FAILED
Execution of cmd : tag failed with exit code: 255.
Working directory was:
/var/lib/hudson/jobs/SoftSmithy-Utility-Library-Release
Your Hg installation seems to be valid and complete.
Hg version: 1.7.5 (OK)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An error is occurred in the tag process: Exception while executing SCM command.
Error while executing command tag --message [maven-release-plugin] copy for tag softsmithy-lib-v0.1 softsmithy-lib-v0.1
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred in the tag process: Exception while executing SCM command.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: An error is occurred in the tag process: Exception while executing SCM command.
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:215)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: An error is occurred in the tag process: Exception while executing SCM command.
at org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:113)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
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)
... 20 more
Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM command.
at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:63)
at org.apache.maven.scm.provider.hg.HgScmProvider.tag(HgScmProvider.java:239)
at org.apache.maven.scm.provider.AbstractScmProvider.tag(AbstractScmProvider.java:706)
at org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:109)
... 24 more
Caused by: org.apache.maven.scm.ScmException: Error while executing command tag --message [maven-release-plugin] copy for tag softsmithy-lib-v0.1 softsmithy-lib-v0.1
at org.apache.maven.scm.provider.hg.command.tag.HgTagCommand.executeTagCommand(HgTagCommand.java:105)
at org.apache.maven.scm.command.tag.AbstractTagCommand.executeCommand(AbstractTagCommand.java:81)
at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
... 27 more
I tried to run
/bin/sh -c cd /var/lib/hudson/jobs/SoftSmithy-Utility-Library-Release && hg tag --message '[maven-release-plugin] copy for tag softsmithy-lib-v0.1' softsmithy-lib-v0.1
and it worked fine!
Any ideas what is going wrong?
PS: I noted that on the following site:
http://maven.apache.org/scm/matrix.html
it is mentioned that the Mercurial tag command is not supported, but it seems to execute the command (and then fails somehow). How can I use the Maven Release Plugin with Mercurial?
PPS: This only seems to happen for multi-module projects. Single POM project runs fine. I tried -DpreparationGoals="clean install" but it didn't help.
I finally found the solution:
The required parent POM
<groupId>org.sonatype.oss</groupId>
<artifactId>oss-parent</artifactId>
<version>6</version>
uses Maven Release Plugin version 2.0
Unfortunatly, there is an issue with multi-module projects using Mercurial.
The issue goes away, when using version 2.1
Work-around: override the version in the project POM/ project parent POM.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.1</version>
<configuration>
<mavenExecutorId>forked-path</mavenExecutorId>
<useReleaseProfile>false</useReleaseProfile>
<arguments>-Psonatype-oss-release</arguments>
</configuration>
</plugin>
I filed an issue here:
https://issues.sonatype.org/browse/OSSRH-1388
If you look at the source file for HgTagCommand.java, it includes a few places where this kind of exception is launched (i.e. "Error while executing command"):
The one regarding tag [message] is:
ScmResult result = HgUtils.execute( branchConsumer, getLogger(), workingDir, branchCmd );
HgScmProviderRepository repository = (HgScmProviderRepository) scmProviderRepository;
if ( !result.isSuccess() )
{
throw new ScmException( "Error while executing command " + joinCmd( branchCmd ) );
}
And that don't look compatible with a multi-modules project, where you can have multiple Mercurial repositories.
I had the same problem, it was because of maven release makes 3 commits (at least in mercurial):
Prepare the release
Make the tag of the release
Prepare for next development iteration
And sometimes if your project or release plugin´s configuration is not right configured, the release get stuck in the first commit. The problem is that sometimes it already updated the release into your sonatype server, so you have to delete this fake release from the sonatype server, configurate well your parent project´s pom.xml, compile the project, and release again.
This is how i looked while i delete my false release 1.0.0-alpha5 in the project bridje-parent:
Also delete the fake release located in its submodules. Remember to commit changes in your scm server before making a release.
Vote if it worked for you, it happened to me very seldom.