Set vm default arguments via maven for eclipse - eclipse

I want to specify vm args of -Djava.library.path=./src/main/resources so that a dll is picked up automatically, and I want to specify this in maven, so other developers don't have to manually configure eclipse.
I was thinking perhaps the the maven eclipse plugin might help, so I could do something like
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.7</version>
<configuration>
DO MAGIC HERE ???? <<-----
</configuration>
</plugin>
But I can't see a way to add VM args from within the plugin.
I have fixed this for running my tests via maven at the command line by
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.3</version>
<configuration>
<argLine>-Xmx768m -Xms128m -Djava.library.path=${basedir}/src/main/resources/</argLine>
</configuration>
</plugin>
My current solution, is that I will have to tell the developers to add this manually to eclipse which doesnt seem very good.
Has anybody got any ideas as to how to solve this.
cheers,
David.

Maybe this should be a more general question:
Is there any way of adding a DLL to the VM without having to specify it through the library path?
I've read somewhere that putting the dll in the application root and specifying the DLL in the MANIFEST.MF with its hashcode triggers the VM to automatically pick it up. That could be completely wrong though.

My interpretation of your problem is that your application is loading a DLL and this DLL is located in your project in the resources folder. Correct?
You can get the full path of the DLL if the DLL is inside a folder in the class path and load it using:
// assuming dll is located in the default package
URI dllUri = this.getClass().getResource("/mydll.dll").toURI();
File dllFile = new File(dllUri);
System.load(dllFile.getCanonicalPath());
This is independent of maven. There are only two problems:
The solution is not system independent since you specify the suffix of the file in the parameter to getResource()
This won't work if the DLL is inside a JAR. For this case we build a JAR extractor which will extract the DLL to a temp folder and call System.load() with the file in the temp folder.

Related

Force unpacking with maven-dependency-plugin

Im am using Maven 3.2.1 with Eclipse Kepler. I have a dynamic web project which has a dependency to another component which includes some JSPs. I now want the JSPs from the dependency to become part of the web root of the dynamic web project. I chose to accomplish this by using unpack goal of the maven-dependency-plugin.
I added a plugin definition to unpack the JARs into /target/m2e-wtp/web-resources. Unfortunatley Eclipse from time to time cleans this folder and teh JSPs are gone. In order to unpack them again I have to delete the target/dependency-maven-plugin-markersfolder. Otherwise the plugin will not unpack the files again.
Is it possible to force the unpacking and ignore the plugin markers?
Is there a better way to get web resources from a dependency into my Dynamic Web Project?
Yes there's a better way, but it's not compatible with Tomcat's "serve module without publishing" feature (or Weblogic's equivalent thing)
Remove your maven-dependency-plugin configuration and add your dependency as a war overlay instead. If your dependency is a war, it'll be automatically recognized as an overlay (http://maven.apache.org/plugins/maven-war-plugin/overlays.html). If it's a zip or a jar, you need to add a specific configuration to your maven-war-plugin definition. Something along :
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<overlays>
<overlay>
<!-- /!\ must also be added as a project dependency-->
<groupId>foo</groupId>
<artifactId>bar</artifactId>
<type>jar</type>
<targetPath>relative/path/to/contextroot</targetPath>
</overlay>
</overlays>
</configuration>
</plugin>
Before deployment, resources will be unzipped under target/m2e-wtp/overlays/bar-version.jar/ and then deployed onto your application server

GWT maven compiler output directory

I need to set output directory location for GWT compiler using maven plugin.
I've investigated the GWT compiler and gwt-maven-plugin docs and did not find any options for this.
For example:
I have two modules named editor and console and gwt-maven-plugin compiles them to %ROOT%/editor and %ROOT%/console dirs.
But I need to have these modules compiled into %ROOT%/ria/editor and %ROOT%/ria/console dirs to reduce effort to maintain the URL based security and other stuff.
Is it possible to set ria directory in plugin configuration to avoid unneeded new ANT task creation for moving compiled modules stuff to needed place?
I had to un-check the checkbox highlighted in the below screenshot
<plugin>
<artifactId>gwt-maven-plugin</artifactId>
<configuration>
<webappDirectory>${project.build.directory}/${project.build.finalName}/ria</webappDirectory>
</configuration>
</plugin>
See http://mojo.codehaus.org/gwt-maven-plugin/compile-mojo.html#webappDirectory
It won't play well with the DevMode though, unless you run in -noserver mode (which I'd recommend anyway for any middle-sized/big project)

Can Maven (jar/war) packaging be avoided if there are no source file changes?

I would like to be able to intelligently decide whether a web application has changed and needs to be redeployed, but can't determine an effective way of doing so with Maven2.
For a given Java web application Maven won't recompile unchanged source files, but it will always repackage the .war artifact, thereby updating its timestamp. With an updated timestamp, I have to assume the artifact represents an updated snapshot version.
Is it possible to have Maven avoid repackaging where no source files have changed and a previously packaged .war file is still present in the target folder? At the very least, is it possible to have Maven avoid overwriting the previously packaged .war file if no changes were found?
You can try the setting of the maven-war-plugin which is by default set to true (force). But be carefull and read the warnings about the force flag in the docs.
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<archive>
<forced>false</forced>
</archive>
</configuration>

Eclipse/Maven: JUnit tests not compiled when running them

I am working on a project using Maven and Eclipse (m2eclipse plugin). I've got problems with the JUnit tests:
Sometimes, when running them within Eclipse, they wont be compiled, but the old class files are used instead. When I delete the class files, I get ClassNotFoundExceptions in Eclipse. I then have to manually recompile them by using mvn test-compile or other goals.
I also noticed that the class files of the tests sometimes are put into the classes subdirectory instead of test-classes.
I really can't figure out what is wrong.
The JUnit java files are within src/main/java and are correctly named (*Test.java).
Do I have to compile and run them always via Maven? Why doesn't Eclipse compile the files when I want to run them? (Interestingly, sometimes it does. Sometimes everything works perfectly.)
I had the same problem with STS Eclipse (Spring development variant), m2e and JUnit. The solution was to set the output folder for src/test/java to target/test-classes:
Right click the src/test/java folder in the Package Explorer
Select Build Path -> Configure Output Folder
Enter target/test-classes, click OK
Now the changes in test classes are compiled correctly and you should be able to run JUnit tests in Eclipse.
The problem is that Eclipse compiles the unit tests to the default output folder target/classes while JUnit plugin correctly tries to run them from test-classes.
There are a few duplicates to this question:
ClassNotFoundException when running JUnit unit tests within Eclipse (using Maven)
Eclipse doesn't see my new junit test
junit not using the newest file
In addition to the answer below
Right click the src/test/java folder
Select Build Path -> Configure Output Folder
Enter target/test-classes, click OK
you should check to ensure that your builder is setup correctly by right clicking your project and going to Properties -> Builder. If you see that your builder is missing, you need to install one. In my case, the maven project had an AspectJ dependency and when I used the Maven Eclipse plugin to build my Eclipse project, it was looking for an AspectJ builder by default. I installed the AspectJ development tools and it solved the problem.
Hope this helps!
The most likely explanations for the problem you are facing is that the output folder of src/test/java is not correctly configured.
Instead of fixing this configuration manually, you can have m2eclipse fix this for you: Just right-click on the project and choose Maven > Update Project.
And another point: JUnit test classes should be in src/test/java, not src/main/java, otherwise they aren't detected correctly by Maven as test classes and they would be included in the packaged jar and not in the test jar.
I faced same issue. Tried above suggestions of configuring output folder & Maven>Update Project but neither worked. Finally changed my testOutputDirectory to "build/classes" as well and now Unit Tests are getting picked up and executed.
Finally found the reason for the issue. In my pom we had also configured maven compiler plugin as below
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<outputDirectory>build/classes</outputDirectory>
</configuration>
</plugin>
outputDirectory configuration is not needed and was the cause of above issue. After removing this tag, junits are getting compiled to build>testclasses folder and are being run during maven build as well. Yippee :)
Please check "testSourceDirectory" path which can be configured in your
pom.xml. And then, Add the folder (configured in "testSourceDirectory" path) to the eclipse build path.
Please find the sample "testSourceDirectory" in pom.xml below:
<build>
<testSourceDirectory>src/test/java</testSourceDirectory>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
Make sure that is there any exclamation mark on your project icon! In my case, i ignored that there is a exclamation point like:
exclamation point on project icon
Open the "Markers" perspective, then troubleshoot the problems according to the tips.
what the "Markers" perspective show
The junit test classes can be execute successfully after i called "mvn clean test" because they are not refer the unreadable jar which be warned in "Markers" perspective.Therefor, it's easily to ignore it..
For someone working on java-scala mix project, this is something to note.
Even after doing the configuration in the manner shown below,
<build>
<testOutputDirectory>${basedir}/target/test-classes</testOutputDirectory>
<plugins>
...
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>scala-maven-plugin</artifactId>
<version>3.3.2</version>
<configuration>
<testSourceDir>${basedir}/src/test/scala</testSourceDir>
<testOutputDir>${basedir}/target/test-classes</testOutputDir>
</configuration>
</plugin>
</plugins>
</build>
and doing a Maven > Update Project, eclipse honours the output directory of the src/test/java folder in the project, however, not for the src/test/scala folder. (You can figure this out by right-clicking on the specific source folder and choosing Build Path > Configure Output Folder... which should display the location as specified in the pom for the former case, however, not for the later case.
This is already a known bug for using scala with m2e as mentioned here: http://scala-ide.org/docs/tutorials/m2eclipse/
Warning
As of March 2013, a bug causes both src/main/scala and src/test/scala to use the default output folder (target/classes). This may be confusing >when building tests, since their class files will not end in target/test-classes, as they would when building on the command line. You can work around this by manually changing the output folder for src/test/scala.
Eclipse is not expecting anything else to be mucking with the class files. It assumes that if you haven't editted the file in eclipse it hasn't changed and doesn't need compiling. I think the issue stems from eclipse and maven sharing an output directory. I've often seen this if my mvn build fails, it will have deleted the class files as part of the clean but not compiled new ones. I think the best solution would be to have seperate build dirs for mvn and eclipse, but I've never look into this.
My problem wasn't the JUnit plugin but rather the configuration in my pom.xml.
After reviewing all the answers to this question, #Gulats's answer implied to me that I should try setting a testOutputDirectory in my maven-compiler-plugin section, and that did the trick:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
<testOutputDir>${basedir}/target/test-classes</testOutputDir>
</configuration>
</plugin>

How to add a jar to the server lib for *embedded* JBoss?

I need to add a crypto provider to the embedded JBoss used by Seam for integration tests.
For the regular JBoss it's a simple matter, just drop the files into the /lib folder of the server instance. With the embedded JBoss, however, things seem to be different. I've tried putting the jars in /embedded-jboss/bootstrap/lib and /embedded-jboss but no change, the classes are not seen.
I've read http://community.jboss.org/wiki/EmbeddedAndJavaSE and also looked in the source of org.jboss.embedded.Bootstrap but I haven't found a way yet. The build is done with Maven if it matters.
Thanks a lot for any suggestions.
I found an answer in the meantime: they can be added to the classpath of the plugin that runs the tests, like below. Works for me.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!-- snip -->
<additionalClasspathElements>
<additionalClasspathElement>add/here/your/jar</additionalClasspathElement>
</additionalClasspathElements>