I'm having an issue with a maven build in hudson. This issue would be fairly easy to resolve if I could see the output of maven with the -X flag passed in. However I can't find a way to do this. If I specify "-X" in the "Goals and options" field of the "Build" section in the job configuration my console output looks exactly the same as if I had not passed the "-X" flag at all. Is the debug logging going somewhere else? Or is there some other way I need to pass the "-X" flag?
UPDATE:
The reason this isn't working is because the build is failing during the "Parsing POMs" part of the hudson process, before it actually kicks off the true maven build and passes in any params I specify in the project. So what I really need is a way to get better logging during the "Parsing POMs" part of a maven build in hudson.
That's what it says in the help text.
Specifies the goals to execute, such
as "clean install" or "deploy". This
field can also accept any other
command line options to Maven, such as
"-e" or "-Dmaven.test.skip=true".
I would have put it there as well.
The maven help gives me the following two options:
-X,--debug Produce execution debug output
-e,--errors Produce execution error messages
May be you can try the --debug or the -e swtich
In Jenkins, and I assume this is true for Hudson as well, command line arguments can be passed to Maven in the "goals" setting. I was able to pass the -X parameter by adding it to the beginning of the "goals".
-X package install
Jenkins apparently blindly appends this setting to the end of the mvn command-line.
I have exactly the same problem with Hudson 1.398 (Maven 2.0.10, jdk 1.6.0_07): the build fails during the parsing of the pom files. It works locally and when launched manually from the Hudson workspace.
That build needs an environment variable to be set (for the path of a module), but the environment variable doesn't seem to be propagated from Hudson to Maven. So, like you, I have also tried to get more details from Maven with the -X option, but it also doesn't seem to be propagated.
Related
Simple question. How do I set the build configuration to something other than Debug?
Setting /P:Configuration=Staging in the Command line parameters box, leads to this error:
TeamCity says to use "Build Parameters" instead of "/property:" in an MSBuild step. What does that mean?
So how is it done? I need to build MSDeploy packages for all configurations, I can get the packages to build but everything is Debug.
The way you're doing it is fine -- although perhaps use a lowercase /p:. Our team does it this way too. TeamCity isn't throwing an error, it's just trying to provide some helpful information.
JetBrains provides some documentation for its preferred method at the bottom of the page under Using System Properties in Build Scripts.
what options to maven can I use to determine what classpath maven is running a testng test case with?
You didn't provide the Maven version, but at least in 3.x (and maybe also 2.x) you can run commands with the -X (debug) option. That way the Test Classpath is printed out before tests are run.
mvn test -X
In general you can find the classpath that maven is using by using the built-in maven dependency plugin and its build-classpath goal.
If you want the classpath uses for compiling and running the test you need to select the test dependency scope. This scope is the default, but if you want to be explicit you can set it with -DincludeScope=test.
Other scopes include runtime, compile, provided and system.
Depending on how you want to consume the output you can play with the options -Dmdep.outputFilterFile and -Dmdep.outputFile. The mdep.outputFilterFile makes it easier to parse the output from a script and the outputFile option writes to a file instead which some tools can read directly.
Here are some examples:
$ mvn dependency:build-classpath -DincludeScope=test -Dmdep.outputFilterFile=true|grep 'classpath='
classpath=xxx.jar:yyy.jar
$ mvn dependency:build-classpath -DincludeScope=test -Dmdep.outputFile=cp.txt
$ cat cp.txt
xxx.jar:yyy.jar
I couldn't format my response in my comment so submitting the grepped version here:
mvn test -X | grep "maven.dependency.classpath"
I have a Maven project which has many a set of customer-specific modules of which one is used. The command to execute this build is as follows:
mvn clean install --projects [targetModule] --also-make
Normally I would use profiles to configure module selection and it appears that the end result is similar in this case. I cannot seem to find any documentation on this --projects flag and its semantics which is making me hesitant to specific a different set of modules. Does anyone know how --projects and/or --also-make works or where I might find documentation on them?
mvn --help gives some information regarding this.
-am,--also-make If project list is specified, also
build projects required by the
list
-pl,--projects <arg> Build specified reactor projects
instead of all projects
I have a Hudson job that runs a maven goal. Before this maven goal is executed I have added a step to run before the build starts, it is a shell script that obtains the version number that I want to use in the 'Goals and options' field.
So in my job configuration, under Build Environment I have checked the Configure M2 Extra Build Steps box and added a shell script before the build. The script looks like this:
export RELEASE={command to extract release version}
echo $RELEASE
And then under the Build section I point to my 'root pom'. In the Goals and options I then want to be able to do something like this:
-Dbuild.release.version=${RELEASE} deploy
Where build.release.version is a maven property referenced in the POM. However since the shell doesn't seem to make its variables global it doesn't work. Any ideas?
The only one I have is to install the Envfile plugin and get the shell script to write out the RELEASE property to a file and then get the plugin to read the file, but the order in which everything is run may cause problems and it seems like there must be simpler way...is there?
Thanks in advance.
I recently wanted to do the same, but AFAIK it's not possible to export values from a pre-build shell to the job environment. If there is a Hudson Plugin for this I've missed it.
What did work, however, was a setup similar to what you were suggesting: having the pre-build shell script write the desired value(s) to a property-file in the workspace, and then using the Parametrized Trigger Plugin to trigger another job that actually does the work (in your case, invoke the Maven job). The plugin can be configured to read the parameters it passes from the property file. So the first job has just the shell script and the post-build triggers, and the second one does the actual work, having the correct parameters available as environment variables.
General idea of the shell script:
echo "foo=bar
baz=`somecmd`" > build.properties
And for your Goals and options, something like:
-Dbuild.release.version=${foo} deploy
Granted, this isn't as elegant as one might want but worked really well for us, since our build was broken into several jobs to begin with, and we can actually reuse the other jobs that the first one triggers (that is, invoke them with different parameters).
When you say it doesn't work, do you mean that your RELEASE variable is not passed to the maven command? I believe the problem is that by default, each line of the shell script is executed separately, so environment variables get lost.
If you want the entire shell script to execute as if it was one script file, make the first line:
#!/bin/sh
I think this is described in the Help information alongside the shell script build step (and if I'm wrong, that's a good place to look for the right syntax).
I want to automate the execution of Maven release:prepare with Perl so that the user doesn't have to answer the prompts for version names etc. Are there a -D arguments that can be supplied so that no prompting is done? I tried the obvious solution which is to feed the prompt answers to mvn via perl code like this:
my $cmd = qq(mvn release:prepare -DautoVersionSubmodules=true-DpreparationGoals="clean install");
open MVN, "| $cmd";
print MVN "\n"; # default
print MVN "$cur_version";
print MVN "\n";
print MVN "$next_version";
print MVN "\n";
close MVN;
but mvn ignores such input and winds up using the defaults (and doesn't prompt either).
So, are there -D args for the release:prepare plugin:goal?
Thanks.
You can use the following maven command to do that...
mvn --batch-mode release:prepare
This will assume defaults for anything that you would normally be prompted for; it would be like running a release and simply hitting enter every time it asked you a question. For instance, if your current development version of your project was 1.2.3-SNAPSHOT, it would release version 1.2.3 and move your development version up to 1.2.4-SNAPSHOT. It is usually best to let Maven work this things out for you anyway since the goal of maven is to use convention over configuration. However, is you need to specify non-default properties, the maven-release-plugin allow command line property override as well as using a 'release.properties' file for overriding these settings.
For the Maven part, see Performing a Non-interactive Release.
If it is a Perl solution you seek, command-line arguments are usually executed through the system command.
Try system $cmd;
As far as I can tell, there's no need to open and close filehandles.
You can specify everything using arguments to the mvn release:prepare command:
mvn release:prepare -DautoVersionSubmodules=true -DreleaseVersion={your release version} -DdevelopmentVersion={next version}-SNAPSHOT -Dtag={your tag}