I want to spare the time typing a -T3 on the command line as I want all the maven builds I will ever do to run multithreaded.
Maven 3.3.9
I googled but didn't find anything promising, only the suggestion to add an environment variable for command line opts and append that to every maven call on commandline.
Maven: configure parallel build in pom.xml
This way, every time, still a manual step is required (entering the environment variable's name) to do a parallel build.
I'd like to configure that globally in the mvn settings.xml file.
You can't configure thing like this settings.xml. This can be configured differently since Maven 3.3.1.
You can use a file ${maven.projectBasedir}/.mvn/maven.config which contains the options given on command like within the root directory of your project which simply can contain:
-T 3
but this is limited on a project base not always.
Related
I would like to add my own commands to delete a specific folder in the mvn repository whenever I run a maven command.
For using maven through the command prompt, this is quite easy since we just update apache-maven-3.5.3\bin\mvn.cmd .
However, I noticed that when we run mvn from intelliJ Maven projects Tool Window, the command run is the following:
C:\mbakOrg\Oracle\JDK\jdk1.8.0_60\bin\java -Dmaven.multiModuleProjectDirectory=
C:\mbakOrg\_CODE\MNE_ARCHIT_GIT\_REPOS\sg-template-store -Dmaven.home=C:\mbakOrg\build\apache-maven-3.5.3 -
Dclassworlds.conf=C:\mbakOrg\build\apache-maven-3.5.3\bin\m2.conf "-javaagent:C:\mbakOrg\devel\JetBrains\IntelliJ IDEA
2017.1.3\lib\idea_rt.jar=42633:C:\mbakOrg\devel\JetBrains\IntelliJ IDEA 2017.1.3\bin" -Dfile.encoding=UTF-8 -classpath
C:\mbakOrg\build\apache-maven-3.5.3\boot\plexus-classworlds-2.5.2.jar org.codehaus.classworlds.Launcher -Didea.version=2017.1.3 clean install
So how will I add a command that will run every time?
Since maven in InteliJis using a custom way to run maven.
Explanation
My problem is basically that the mvn -U command does not properly pull the newest code all the time. Additionally, we are all using a snapshot of a parent project that is being updated quite often to fix issues.
I would strongly discourage modification of mvn.cmd. Even if you figure out how to do it in command line, and in InteliJ, then think about moving to some kind of Continuous Integration framework, like Jenkins for example, which will use default mvn.cmd?
If there is no possibility to achieve what you want with existing Maven tools, I would recommend writing own Maven plugin, (see this tutorial), and put required functionality there. It will guarantee, that this particular piece of code will be executed in all the environments, and this is the way to make sure, that the command will be launched every time.
I am running Eclipse with Maven, eGit and TestNG plugins, with my tests running against SauceLabs.
I would like to get the project's current Git branch name in the Maven run configuration so my code can see it at runtime and name the SauceLabs session appropriately.
A typical current Maven goals line in a run configuration looks like this:
-DtestNG.suiteXmlFile="config/regress_saucelabs.xml" clean -X test
I would like to be able to write something like the following instead:
-DtestNG.suiteXmlFile="config/regress_saucelabs.xml" -Dgit.branch=$ECLIPSE_GIT_BRANCH clean -X test
where ECLIPSE_GIT_BRANCH is an Eclipse variable that gets substituted when the run configuration is used.
Runtime solutions are a last resort, because the test code needs to also run in environments where the source repository is not available.
Strongly prefer injecting the branch name at build time, on the Maven command line. Getting it as a POM variable would work well too.
I have never use it but it looks like JGit is what you are looking for (https://doc.nuxeo.com/blog/jgit-example/)
Another solution is to call the shell command git branch in Java and then parse the result.
Another solution using maven plugin is explained here : Put current git branch to project version
I would need to execute a specific Maven plugin from command line. For example, in the following I execute a specific version of Maven Surefire Plugin to test Java projects:
mvn org.apache.maven.plugins:maven-surefire-plugin:2.19-SNAPSHOT:test
However, the above assumes to find the surefire plugin 2.19 in the default Maven repository path. Now, my question is, if I want to use the plugin with a specific path (not Maven default one), what should I do using the command line? I would expect something like the following, without modifying pom.xml:
mvn /path/to/some/jar/version/org.apache.maven.plugins:maven-surefire-plugin:2.19-SNAPSHOT:test
or more generally, for the following invocation
mvn groupId:artifactId:version:goal
I would need somewhere to specify a customized path to execute its goal
mvn /some/path/to/groupId:artifactId:version:goal
On the other hand, please let me know if this is not even supported by Maven.
This is not how it works. Maven will always look-up artifacts inside your local repository. And if it can't find it in your local repository, it will try to download it from configured remote repositories.
As such, you don't specify a path to a plugin. You specify a path to a local repository, where that plugin is installed. In this local repository will be installed all the dependencies of the plugin you're trying to invoke. This also means that you cannot have a JAR to a plugin "sitting around" anywhere; it needs to be located inside a correct repository tree directory. With a local repository of /my/local/repo, the artifacts of the plugin groupId:artifactId:version must be located in /my/local/repo/groupId/artifactId/version and be named artifactId-version.jar (and .pom). In the same say, the location of the dependencies of that plugin must follow that directory structure.
By default, the local repository is located inside ~/.m2/repository. But you can change that by:
Specifying the maven.repo.local system property on the command line, for example with mvn -Dmaven.repo.local=/path/to/local/repo groupId:artifactId:version:goal;
Use a custom settings.xml and tell Maven to use it with the -s command line option. It would contain:
<settings>
<localRepository>/path/to/local/repo</localRepository>
</settings>
and be used with mvn -s /path/to/settings.xml groupId:artifactId:version:goal
My pom.xml has scm configuration as follows
<scm>
<url>${my.scm.url}</url>
</scm>
I have property file which I am reading using properties-maven-plugin which has the value of ${my.scm.url}, and also I am using buildnumber-maven-plugin to get latest revision from SVN.
The issue is buildnumber-maven-plugin throws invalid scm url error but, when i replace ${my.scm.url} with actual url to my svn repo , it works perfectly.
How can I achieve successful execution without having to hard code scm url ?
PS: I run build using : mvn clean install command.
The problem is probably due to the order that the plugins run. The following should work:
Bind the properties-maven-plugin to the initialize phase
AFTER that plugin configuration in the POM, add the buildnumber-maven-plugin plugin
AFTER the previous two, put the buildnumber-maven-plugin plugin (which by default bind to the initialize phase).
Now all 3 plugins should run in the correct order (you can check this from the logs). Alternatively you can bind the to different phases to ensure that they run in the correct order, but the above should be enough and conforms with the goal of the initialize phase (initialize build state, e.g. set properties or create directories).
Because you didn't post the POM file, I'm guessing a bit.
Obviously, the order is going to matter, you must get the properties loaded first. That said, looking at the mojo, I'm not sure setting properties is the equivalent of essentially setting a -D.
If you did a mvn -Dscm.url= clean install, then the value would be there because it's being defined to the mvn JVM. Depending at what point the ${scm.url} is being evaluated, if it's before the properties mojo has a chance to run, it's going to be too late.
If you use a CI tool (i.e. Jenkins, Hudson) that can load the properties before the mvn call, then the variable is defined.
I've used the buildNumber mojo for my builds, because I have buildNumbers automatically generated for my snapshot artifacts. The order things occurred:
property file is downloaded from Jenkins master to slave for this job
Jenkins plugin loads the properties file into the job
maven build starts, the build number is already defined before mvn is called (again, behaving like a -D) and my buildNumber is incorporated into my artifact version
buildNumber mojo causes the property file to have buildNumber incremented
property file copied back to Jenkins master
I also wanted to load the properties file within maven and have it "update" the artifact id on the fly, but by that point, Maven had already evaluated; hence, I had to do it beforehand.
Hope this helps.
Prehistory
Our project builds with maven. We use eclipse.
In project i have two DB property file:
jdbc.test.properties
jdbc.prod.properties
with the same structure:
jdbc.driverClassName=
jdbc.url=
jdbc.username=
jdbc.password=
value of username and password in files are different. So we use different schemes for testes and production.
In data-access-config.xml i have the following line:
<context:property-placeholder location="classpath:jdbc.${db.flag}.properties"/>
What i do:
i click "maven install" (in context menu in eclipse)
maven building process runs
What i want:
the environment variable "db.flag" was set to "test" during test
phase
the environment variable "db.flag" was set to "prod" during other
phases
Now i use bat file:
call mvn test -Ddb.flag=test
call mvn install -Ddb.flag=prod -Dmaven.test.skip=true
But it is not an issue for my team.
How should I configure the eclipse to make use of different values of environment variable for different maven phases, during maven building process?
I'll be glad to any advice.
I suggest keeping each copy under the same name (jdbc.properties) in src/main/resources and src/test/resources likewise, so the test phase can pick up your 'test' settings automatically and your location attribute is no longer needed.
Maven will make sure that the test resources are only used at the test phase.