The maven-surefire-plugin supports using the java.library.path property by means of the <argLine> configuration option.
I need to pass the java.library.path property to sql-maven-plugin (which doesn't have an <argLine> configuration option) in order to use the jTDS driver with windows authentication (needs ntlmauth.dll).
Thanks in advance for your help.
The surefire plugin is a special case; it runs the tests in a separate JVM. Most maven plugins don't do this, they run in-process.
So you are out of luck with that plugin config.
One workaround you can try is to use the exec:exec goal of the exec-maven-plugin instead, specifying java with -Djava.library.path on the executable line and roll your own SQL-executing java code.
Otherwise, you can add -Djava.library.path to your MAVEN_OPTS environment variable, which will affect all plugins and all maven builds (which might be fine, depends on your setup), or add it every time to the mvn command line.
Related
How to specify JDK in maven jetty plugin?
Like this:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty-maven-plugin.version}</version>
<configuration>
<scanIntervalSeconds>2</scanIntervalSeconds>
<webApp>
<contextPath>/${project.build.finalName}</contextPath>
<jettyEnvXml>${project.basedir}/src/over/here/jetty-env.xml</jettyEnvXml>
</webApp>
<httpConnector>
<port>8080</port>
</httpConnector>
<!--<executable>${env.JAVA_IBM_HOME}/bin/javac</executable>-->
</configuration>
</plugin>
Please note: the excutable tag is incorrect, I just use it as an example.
To clarify: you actually want to specify an executable, so probably an JRE (Java Runtime Environment) and not a JDK (Java Development Kit). While it is true that JDK serve as JRE as well, this is a required clarification in my opinion.
Coming to your question, there is no such a think to specify a different JDK/JRE used to execute a certain Maven plugin: plugins are executed as part of the mvn command, which in turn is executed using the system JDK/JRE by default (set in the path) and it is actually a script which invokes a plain Java main, yes, Maven it's written in Java and its execution starts from a Java main, the following one to be clear:
org.codehaus.plexus.classworlds.launcher.Launcher#main
If you want to change the JRE used to launch this main, you need to change the JAVA_HOME variable upfront, as also explained by this old SO post.
So you would need the following:
set JAVA_HOME=path_to_your_different_jdk
mvn jetty:run
In your IDE and according to the screenshot you posted in your answer, you are actually doing the same: setting which JVM must be used.
This is true for most of the plugins, unless a specific forking mechanism is foreseen. For instance:
The Maven Surefire Plugin provides a fork mechanism via the reuseForks option and the jvm option, which also explains that:
Option to specify the jvm (or path to the java executable) to use with the forking options. For the default, the jvm will be a new instance of the same VM as the one used to run Maven.
The specified JVM (JRE or JDK used as JRE) will then be used to executed the tests (basically the same scenario you were looking for concerning the Jetty Maven Plugin.
The Maven Compiler Plugin also provides a fork option which can then use an executable option where you can effectively point at a different JDK (and not JRE in this case) to compile your code.
Sets the executable of the compiler to use when fork is true.
The Jetty Maven Plugin is executed as part of the Maven command (again, a Java main using the JRE specified by the JAVA_HOME variable or the default of your system), as also specified in its official documentation:
The classpath of the running Jetty and its deployed webapp are managed by Maven
...
For example, you might need to run your webapp in a forked instance of Jetty, rather than within the process running Maven;
And indeed a run-forked goal is provided
This goal allows you to start the webapp in a new JVM, optionally passing arguments to that new JVM. This goal supports the same configuration parameters as the jetty:run goal with a couple of extras to help configure the forked process.
This option however is mostly used to pass different arguments to Jetty rather than a different executable (for example, in case you already set the same argument for Maven and you want it with a different value for the Jetty run). So, again, the option is not there (to specify which executable/jvm to use for this forked execution). That's a pity, because they got almost there with this goal.
I think I got the answer by myself, but I still don't know how to do it in maven xml file, if you know it, please tell me.
I'm using the cargo plugin to deploy my app to a remote server during the build. To do this, I have a configuration element for the cargo plugin. Since there are two executions that use this single configuration, I use a global configuration element, i.e. it's not inside the executions.
I also want to execute a CLI invocation of the cargo:run mojo on this pom. However, I don't want this execution to use the configuration at all.
How can I do this?
Check out maven profile. It's able to help you to deal with configuration divergence in different environments.
I'd like to know how to specify the path of JRockit libraries to Maven to use , same as we do for eclipse when you specify the JRE .
Also how do i configure maven to use Sun JDK in a project and use JRockit in another project ?
Thanks
A number of options available:
Maven uses the JAVA_HOME environment variable to determine which JVM
should run Maven (Maven is itself a Java program). I recommend this as the first option because build servers like Jenkins can easily control the JVM being used to run Maven.
You can tweak the settings of the compiler plugin to compile using
a different JDK
An alternative approach (clearer to others running your build) would
be to build in a pre-condition check into the POM, using the
enforcer plug-in. Specify a rule that the it should be compiled
using a specified Java version.
My library requires me to bootstrap the JVM in order to run it. In case you do not know, if you pass a jar to the JVM with the -bootstrap option, you can override (substitute) any Java library implementation like java.lang.String, etc.
So all I need to do is tell Maven that when it runs my tests it include the -bootclasspath option with my jar/classes.
Is that possible with Maven? Maybe maven will have to bootstrap itself, if the JVM is not able to add new bootstrap classes on-the-fly as it is able to add new classes/jar to the classpath?
Have you tried the argLine and the forkMode parameters of the surefire plugin?
I'm using Maven to manage my build. For developer testing I use Jetty which I launch using the jetty:run goal in the Jetty Maven plugin. I should also note that I have war:exploded running in an earlier phase which builds the directory that Jetty runs against.
The problem I'm having is that the war:exploded task puts the build dependencies into WEB-INF/lib (as it should) and furthermore, Maven appears to be feeding Jetty the build classpath via the system classloader. This leads to every jar getting loaded twice which should be OK except that, sadly, the Datanucleus library throw an exception the second time it gets loaded onto the classpath.
The only solution I can think of at the moment is to create two profiles, a build profile and a developer test profile. The developer test profile would exclude all the dependencies and jetty:run would run in the developer test profile. This seems like a lot of configuration for something I think would be simple.
Does anyone know if there is a way to prevent Maven from loading the build classpath into Jetty?
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.26</version>
<configuration>
<useTestClasspath>true</useTestClasspath>
...
The option "useTestClasspath" should have the effect you are looking for.