How can I alter the default arguments passed to the mvn executables executed on a Windows system without modifying each installation or manually creating alternative startup scripts (or otherwise "hard-coding" my preferences in a non-portable way)? To be clear, I am not open to external methods like a console alias or using a shortcut or filesystem link. I am asking for a Maven-specific portable way to describe the default startup arguments for all Maven executions on my Windows machine.
Much like MAVEN_OPTS allows you to pass command line arguments to the JVM used to run Maven, MAVEN_CMD_LINE_ARGS is an environmental variable that allows you to pass command line arguments directly to Maven itself (but only on Windows). Unlike modifying files and settings at the level of an individual Maven installation or project (via settings.xml or maven.config for instance), MAVEN_CMD_LINE_ARGS allows you to pass command line arguments to any Maven installation spun up using the provided startup scripts (on Windows the scripts are "mvn.cmd" and "mvnDebug.cmd").
As an example, on my Windows development computer I have set MVN_CMD_LINE_ARGS to
--show-version --global-settings %M2_CONF%\settings.xml --global-toolchains %M2_CONF%\toolchains.xml --define settings.security=%M2_CONF%\security-settings.xml --fail-fast --update-snapshots --strict-checksums --define maven.artifact.threads=8.
Instead of having to place an alias or create my own startup script I simply can use this builtin method to achieve my goal of standardized cross-installation configurations. With MVN_CMD_LINE_ARGS set to that value, executing
mvn
on the command line is actually like executing
mvn --show-version --global-settings %M2_CONF%\settings.xml --global-toolchains %M2_CONF%\toolchains.xml --define settings.security=%M2_CONF%\security-settings.xml --fail-fast --update-snapshots --strict-checksums --define maven.artifact.threads=8.
Now, notice I said that I believe this only functions on Windows. While the Linux Bash scripts include an export of a variable called MVN_CMD_LINE_ARGS they do not then pass it to the mvn executable as an argument. The result of this is that on both Windows and Linux you can use MVN_CMD_LINE_ARGS from after the execution to determine what arguments were used to call mvn, but only on Windows can you use MVN_CMD_LINE_ARGS to instruct which arguments will be used to call mvn. From what I can tell though, this behavior may not be intended, so I would not recommend using this in a critical manner. It seems there is a project specific way to configure the mvn execution arguements via placing them into a "./.mvn/maven.config" file within the projects directory structure.
Related
Newby Maven question...
I am trying to run some tests in a Java Test Automation Framework.
This commmand works fine in linux:
mvn test -Denv.file=src/test/resources/env/.env
However, when I try to run it in Windows I get this error:
Unknown lifecycle phase ".file=src/test/resources/env/.env". You must specify a valid lifecycle phase or a goal in the format
I am presuming that -Denv.file works on Linux but you need a different command on Windows?
I've tried googling but can't find anything.
Along the lines of this answer (which works for me, BTW) and the javadocs, I tried
gradle.startParameter.consoleOutput = org.gradle.api.logging.configuration.ConsoleOutput.Rich
in my ~/.gradle/init.gradle. However, I still need --console=rich to get color output. Why?
Tested with Gradle 2.14.1 and 3.2.1.
Terminal is cygwin urxvt with TERM variable set to rxvt-unicode-256color.
Since Gradle 4.3 you can use org.gradle.console property in gradle.properties:
org.gradle.console=rich
A new console verbose mode will print outcomes of all tasks (like UP-TO-DATE) like Gradle 3.5 and earlier did. You can set this via --console=verbose or by a new Gradle property org.gradle.console=(plain rich verbose).
I am not sure if you can force the rich console from a gradle script, as the detection happens likely before the script is interpreted.
NativeServices class provides the integration with the console. If you look at the source code, there are two messages possibly printed in log:
Native-platform terminal integration is not available. Continuing with fallback.
Unable to load from native-platform backed ConsoleDetector. Continuing with fallback.
The latter might give you more information why. Try running the gradle script with --debug. You will likely find out that you are missing a native library that is either not available in cygwin or it is, but is not on library path.
I believe it works when you specify the rich console from the command line, because gradle forces the colours even though the console doesn't indicate it supports them.
Does it work if you don't use the cygwin console in Windows native command line or maybe GitBash?
There is a workaround how you can make this work. You can create an alias in cygwin that will always add the --console=rich.
If you are using gradle wrapper, you can edit the gradlew script and add the command line parameter. To make it automated, you can change the wrapper task to alter your script in the doLast part.
Create a file called gradle.properties inside your ~/.gradle/ folder.
Inside gradle.properties, add the line org.gradle.console=rich.
Each builds will run under --console=rich automatically because the new gradle.properties will be merged with the gradle.properties of your project.
If your project's gradle.properties contains the same tag as the local file, your project's will be used overriding the local file's
If you are on Linux/Mac set
alias gradle='gradle --console rich'
in your ~/.bashrc.
In Gradle Wrapper, add the following line:
org.gradle.console=rich
to ./gradle.properties in the root folder, where the gradlew script is located.
I'm trying to port a *nix, CMake-based project to Windows. One header file needed by the main library is generated by a custom program, so the CMakeLists.txt file contains something like this:
add_executable(TableGenerator "TableGenerator.cpp")
target_link_libraries(TableGenerator ${LibFoo_LIBRARY})
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND TableGenerator "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
An important detail is that TableGenerator uses the external shared library LibFoo. For example under Linux, everything works fine, because libfoo.so is installed in one of the system library directories like /usr/local/lib, or CMake even sets the rpath attribute in the executable, saying where exactly to find the library.
On Windows, however, these kind of libraries are usually not installed into the system but are rather just extracted or compiled into some arbitrary directory in or near the build tree. In order for TableGenerator to run, the foo.dll would need to be available in or copied to one of the Dynamic-Link Library Search Order paths (say %WINDIR%\System32 or the build output directory for TableGenerator), which is not desirable.
How can I set the PATH environment variable for the custom command, i.e. to be used not during the CMake run but during the actual custom build step runtime?
While still doing my research in order to ask the question properly, I have found three solutions. Considering how hard it was to find this information, I decided to post the question and answer here anyway.
1. Using global variable CMAKE_MSVCIDE_RUN_PATH
There is a special variable dedicated to solving this exact problem – CMAKE_MSVCIDE_RUN_PATH. If set, it results in a line like this being added to the custom build step script:
set PATH=<CMAKE_MSVCIDE_RUN_PATH>;%PATH%
So all that's needed then is something like this at a good place:
set(CMAKE_MSVCIDE_RUN_PATH ${LibFoo_RUNTIME_LIBRARY_DIRS})
I have originally noticed this variable only in CMake sources, because it used to be undocumented until CMake 3.10. So you might not be able to find it in documentation for older versions of CMake, but don't worry, it's been supported since 2006.
Advantages:
▪ Can be enabled at one central place
▪ No change at all in any of the add_custom_command() commands elsewhere is needed
▪ Only the path itself is set, no batch commands need to be written explicitly
▪ The obvious choice with clear name and intent
Disadvantages:
▪ Global for the whole CMake project and all custom commands
▪ Works with the "Visual Studio 9 2008" and above generators only
2. Setting the PATH explicitly using two COMMAND parameters
The script being generated for the custom build step in Visual Studio contains some prologue, then the commands themselves and then some epilogue. Wouldn't it be possible to simply add set PATH=... before the real command through another COMMAND parameter?
The documentation for add_custom_command() says:
COMMAND
Specify the command-line(s) to execute at build time. If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script.
So no, that's not guaranteed to be possible. But the Visual Studio project generator actually does it like this, i.e. the individual commands are just appended one after another, so the following does the job:
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND set "PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%"
COMMAND TableGenerator "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
Advantages:
▪ The PATH can be changed for each custom command explicitly
Disadvantages:
▪ Relies on an undocumented behavior of the generator
▪ It's necessary to rewrite the whole command for Windows and keep both versions in sync
▪ Each custom command must be changed explicitly
3. Using file(GENERATE ...) to create a custom script
The documentation for add_custom_command() quoted above continues:
To run a full script, use the configure_file() command or the file(GENERATE) command to create it, and then specify a COMMAND to launch it.
This is a bit messy because of the additional temporary files and commands:
file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd"
CONTENT "set PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%
%1 ${CMAKE_CURRENT_BINARY_DIR}/Table.h")
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd" "$<TARGET_FILE:TableGenerator>"
DEPENDS TableGenerator)
Notice the awkward way of sending the path to the executable as an argument. This is necessary because the script is writen once, but TableGenerator might be in different locations for different configurations (debug and release). If the generator expression was used directly in the content, a CMake error would be printed and the project would not build correctly for all but one configuration.
Advantages:
▪ The PATH can be changed for each custom command explicitly
▪ A fully documented and recommended solution
Disadvantages:
▪ Very noisy in the CMakefiles
▪ It's necessary to rewrite the whole command for Windows and keep both versions in sync
▪ Each custom command must be changed explicitly
4. Launch the custom command through CMake wrapper
See the other answer below contributed by Dvir Yitzchaki.
I had personally settled on the solution #1 because it was clean and simple, even before it got properly documented and supported by CMake in version 3.10. It should be the best way forward for you as well, unless you need to do something even more special.
There is another way besides what Yirkha wrote and that is to run the executable through cmake and use cmake's -E option to set the environment.
So in your case it will be:
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND ${CMAKE_COMMAND} -E env "PATH=${LibFoo_RUNTIME_LIBRARY_DIRS}" $<TARGET_FILE:TableGenerator> "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
See http://www.cmake.org/pipermail/cmake/2006-March/008522.html for details.
We are in the process of setting up a Jenkins CI server to handle all of our WebDriver tests. Ideally, I would like to have choice build parameters for our QA team to select the server to test (production, etc.) for each build. We have a properties file in place to handle this, so we only need to make changes to that file. Are there any plugins out there that can do what we are looking for?
You could just use a shell build step
echo $MY_BUILD_VAR > $WORKSPACE/somefile
sometimes a plugin is more than you need! (though EnvInject would help if you have a mixture of OSes to support (i.e. *nix and windows) as Windows runs batch files and *nix goes with shell... though the windows version is trivially different
echo %MY_BUILD_VAR% > %WORKSPACE%\somefile
Yes, EnvInject Plugin can read environment from a property file and make it available to the build.
I'd like to write some Subversion (SVN) hook scripts in Groovy. The SVN server will be running on windows, and according to the SVN book:
you would need to supply a program whose basename is the name of the hook and whose extension is one of the special extensions recognized by Windows for executable programs, such as .exe for programs and .bat for batch files.
Apart from installing Groovy on the local machine, setting the GROOVY HOME env var, and adding %GROOVY_HOME%\bin to the PATH, what else do I need to do before SVN can execute Groovy hook scripts?
Thanks,
Don
You should make sure your groovy scripts are associated to grooovy with the correct parameters, in order for Windows to execute them with their options when double-clicking them.
Notice you must set that association in a way that allow groovy script to be run with parameters.
Anyway, seems like a good page on that very subject could help : Debugging Subversion Repository Hooks in Windows
If you're not doing it as Riduidel recommends, you have to create a batch file calling groovy, for a precommit hook, it would be called pre-commit.bat and will be called with the parameters
[1] REPOS-PATH (the path to this repository)
[2] TXN-NAME (the name of the txn about to be committed)
These have to be passed to your groovy script...