Develop Reference

Generate javadoc for test classes of Maven project in Netbeans

I think that the title is pretty self explanatory, how can I achieve that? By default Maven's javadoc plugin generates documentation only for "normal" classes.

You can set additional source paths for the maven-javadoc-plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<sourcepath>${basedir}/src/main/java;${basedir}/src/test/java</sourcepath>
</configuration>
</plugin>
You may also want to tweak other javadoc:javadoc goal settings. You get set the complete list of options at its official site.

I've managed to solve my problem. To generate javadoc of test packages you have to go to properties of Maven project->Actions->Generate Javadoc and there add the goal: javadoc:test-javadoc.

Maven and Eclipse : loading default properties in maven library project and use it in runnable Jar

I believe this problem has been asked before on stackoverflow. And I'd like to mention that I tried the solutions that came with the questions related to mine. The one that came the closest to my problem was:
Load properties file in JAR?. Sadly the solution described there didn't work for me. And due the age of the question I thought asking it again is the way to go.
Heading on to describing my problem.
So currently I'm working on a library project which has been setup with maven and creates an extension for the current Spring AMQP project.
The goal here is to supply a JAR file which can be included into another project to support a specific way of communicating over a message broker.
At this point I'm implementing the configuration option to allow users to configure the messaging client to their liking. But while i was testing the functionality of this feature I hit a problem while using the library in an executable JAR.
While running it in the Eclipse workspace everything seems to work just fine. But when I try to run it from my desktop (as a runnable JAR) the properties file does not seem to be found anywhere.
Just to give a quick overview of the workspace/projects setup as described above:
The project structure of both project reflects the Maven default one:
- src/main/java
- java source files
- src/main/resources
- resource files
- src/test/java
- java test files
- src/test/resources
- test resource files
Where the library file contains a default.properties file in the src/main/resources folder and the chatclient project a custom.properties file.
Once the runnable JAR file has been build it has the following structure in it.
- com
- junit
- META-INF
- org
- resources
- default.resources
- custom.resources
I believe the resource files should not be located there. but in the META-INF/maven folder instead. After trying out stuff like:
Adding a META-INF folder into my src/main/resources folder and putting the property files there.
Adding a MANIFEST file with Class-Path: . in it.
Loading the file in multiple ways in code.
But nothing seems to work. I guess it is Maven related and a simple change in the pom.xml could fix it. Sadly my knowledge on the Maven project setup and pom related subjects is very basic (this is my first project using maven). And I can't seem to find any documentation on it, even though I know it should be there (probably a problem caused by me).
Before I forget to mention it. I load the property files using this way:
Properties props = new Properties();
prop.load(<custom static class>.class.getResourceAsStream(filename));
return props;
Also the pom.xml for my library looks like:
-- Artifact stuff --
<packaging>jar</packaging>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
-- Dependency stuff --
And the one for the project that uses the library look like:
-- Artifact stuff --
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.maxxton</groupId>
<artifactId>async-amqp-messaging</artifactId>
<version>0.2</version>
</dependency>
</dependencies>
-- Other stuff --
I hope there is someone who's a little more advanced on this subject and could help find a solution for this problem. And if you need any additional information on the project files/structure, please let me know. I'd gladly share it with you.
Update (28-04-2015 {1})
For testing I created a sample project which tries to load property files the same way as the scenario described above.
Even while following the Maven documentation (Using the META-INF folder) I was not able to load the properties.
For the sake of this question I uploaded the testing workspace here.
I hope someone could help me fix this, as the normal way as described on the Maven website does not seem to work for me.
Update (28-04-2015 {2})
Well I managed to fix a part of the problem.
Since I added the configuration for the maven-assembly-plugin (building runnable JAR with deps), I was able to get the correct structure within my JAR file.
The thing I added was:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<finalName>project</finalName>
<appendAssemblyId>false</appendAssemblyId>
<archive>
<manifest>
<mainClass>com.test.project.Application</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Then when running clean compile assembly:single I managed to get the right structure.
JAR root
- com
- META-INF
- MANIFEST.MF
- default.properties
- custom.properties
While this fixes a part of the problem. The file loading still results in a NullPointerException.
Final Update (04-05-2015)
After a long Maven struggle I managed to get everything the way I want it to be.
Following the advice given by both #Deepak and #Joop Eggen, I did some research on how to have all the dependencies in a lib folder as jar instead of unpacking them in a 'uber' jar. After trying loads of stuff I stumbled upon this answer. Following the instruction there seems to create this structure:
- runnable.jar
- lib
- spring-amqp.jar
- spring-core.jar
...
When following #Joop Eggen's advice I managed to get the property loaded the way I want to. So it seems this question has been answered. Currently I'm still figuring out how to award each answer as I'm not able to split the bounty into two pieces. I'll get back on that.
Side Note
Although I awarded both the bounty and the answer to #Joop Eggen does not mean that #Deepak's answer did not contribute. It did give some great information on best practice, but was not as complete as the accepted answer. So please when finding your answer here give him some of the credit too.

There are two ways to get resources,
with a ClassLoader against the entire class path using absolute paths (without /...),
with a class, using a relative (...) or absolute (/...) path inside the jar of that class.
The latter seems more direct, and can be used as:
getClass().getResource("/...");
ClassInJar.class.getResource("/...");
Now getClass() is only possible in a non-static object and is dangerous too: the actual class might be some child, not in the library jar.
On the actual structure of your application. I know a maven directory convention:
src/main/java/...
src/main/resources/...
where /... gets into the jar/war; the package directory.
Reassembling jars is not good. There always is the Class-Path: ... entry in META-INF/MANIFEST.MF. Following the basic maven conventions is best.

The solution to this is simpler, however there are couple of concepts that I would like you to be aware off.
It is not a good practice to create one big jar by using maven assembly plugin. In your examples, you are using small jars both developed by you, so it might seem okay. But as your real projects get bigger, this is not ideal, you would want separation of different modules and not one big jar. The ideal practice is opposite to what you are trying to achieve - you should aim to have smaller and smaller jars. You might in future want the convenience of replacing these smaller jars without having to deliver the entire package again.
You would surely not want to unpack 3PP jars and package them as your own jar!
Based on the above, you might wonder how do you create executable jars. Well, the answer is having the dependent jars in the class-path. When executing the "project" jar, you should have the "library" jar in the class-path and it will be able to find the properties file inside as expected.
You places the properties files in META-INF directory. The right place for them is the resources folder. And if you follow the point No.1, things will work as expected.

How to remove default checkstyle in eclipse?

I have a custom checkstyle.xml imported and set as the default. It works great. I just upgraded to the newest version of checkstyle and now I have a warning on just about every line of code. It looks like the warnings are coming from the two build in checkstyle xml's but they are not removable!
How can I disable these two checkstyle rule files so they stop bothering me?

The built-in configurations are not removable and cannot be changed or edited. Instead, people are supposed to create their own configurations, which is just what you did.
There are a few things you can try:
Make sure that your upgrade of the Checkstyle Eclipse plugin was performed correctly. Stop Eclipse. Check the plugins and features folders for contained folders called edu.umd.cs.findbugs.plugin.eclipse_version. There should only be one such folder in plugins and one in features, both with the same version number. If there are more, delete the ones with the older version numbers. Restart Eclipse with the -clean option as first argument.
Make sure that your custom Checkstyle configuration is still the default after the plugin upgrade.
Check the Eclipse projects in your workspace and make sure that they do not have project-specific settings for Checkstyle. Right-click on project, select Properties, then Checkstyle. Make sure that the selected configuration is correct.
Configuration names are case sensitive. This can be an issue if someone made a case mistake in the .checkstyle file located in each project's root directory. Or the configuration name was mistyped on import. This last point should result in different errors though (such as configuration not found).

Looks like Checkstyle locks in the 2 default rule sets. Two options occur to me: 1) Edit the default rules to diable the conflicting rules (or all of them). Or 2) delete the two xml files off the files system from the plugins/checkstyle (whatever the actual dir name is called).

Put the following in the projects that you want check-style disabled for, edit your pom.xml change the check-style skip to true :
<properties>
<!-- Checkstyle -->
<checkstyle.skip>true</checkstyle.skip>
</properties>
you should also configure it like this:
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.17</version>
<executions>
<execution>
<id>validate</id>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<configLocation>checkstyle.xml</configLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<outputFileFormat>xml</outputFileFormat>
<failsOnError>false</failsOnError>
<failOnViolation>true</failOnViolation>
<skip>true</skip>
</configuration>
</execution>
</executions>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Checkstyle will still run, but will perform a no-op...

Maven and GWT (and Eclipse) - Does it really work?

Over the past few days I have been trying to create/run a project in Eclipse using the gwt-maven-plugin and keep running into roadblocks (see some of my previous questions). I like to use Maven to do my builds, but I'm at the point where I'm thinking of going the Ant build route because of the complications of using Maven.
Does anyone out there have it configured/working well? Is it just me or is this harder than it should be?

After much frustration trying to get things to play nicely together, this is the setup I have that "works" for me. "Works" meaning that I can create, run and debug a GWT project with tweaks, but it isn't the most elegant solution.
Create Project
Much of the steps are the same as Pascal's answer in this post: Maven GWT 2.0 and Eclipse. I'll list mine out to be clear.
In Eclipse (Helios) with m2eclipse and GWT Eclipse plugins installed:
Create a new Maven project using the gwt-maven-plugin archetype
Modify the pom.xml:
set <gwt.version property> to 2.0.4
(needs to be same as GWT Eclipse
Plugin version)
set <maven.compiler.source> and
<maven.compiler.target> properties to
1.6
remove <goal>generateAsync</goal>
from gwt-maven-plugin <plugin> config
add maven-war-plugin to pom.xml
maven-war-plugin example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0.2</version>
<configuration>
<warSourceDirectory>war</warSourceDirectory>
<webXml>src/main/webapp/WEB-INF/web.xml</webXml>
</configuration>
</plugin>
Update project Properties:
Google -> Web Toolkit, check the "Use Google Web Toolkit" box, and ensure "Use default SDK (GWT-2.0.4) is selected.
Run Maven "gwt:eclipse" goal on project (sets up environment and launch config)
Copy *.launch file to workspace.metadata.plugins\org.eclipse.debug.core.launches
Restart Eclipse
Compile/Run Project
I created a Run Configuration that does mvn clean compile gwt:run. The gwt:run is necessary to copy the resources and lib jars into the war directory. However, it does not copy the web.xml from src/main/webapp/WEB-INF into war/WEB-INF/. So, I have to manually copy that file.
If I want to run my application, the above step is sufficient. However, if I want to debug the application, I launch it by choosing the Google "Web Application" configuration from Debug Configurations that was created when the .launch file was copied previously. This configuration allows for debugging (breakpoints etc.) without any other config or need for remote debugging.

It is harder then it should be, however it is possible. All hints posted here can do the trick. However you can still have classloading issues. I decided to switch to GWT 2.1 and use new abilities of JettyLauncher. You can create own jetty launcher like this:
public class MyJettyLauncher extends com.google.gwt.dev.shell.jetty.JettyLauncher {
#Override
protected WebAppContext createWebAppContext(TreeLogger logger, File appRootDir) {
return new WebAppContext(appRootDir.getAbsolutePath(), "/");
}
}
And then add -server MyJettyLauncher option to your gwt launcher configuration. With such configuration all the libraries are managed by m2eclipse (you can even remove GWT SDK from classpath) and there is no need to copy anything to WEB-INF/lib (you can remove gwt-servlet.jar which could be already there).
Ready launcher is here in tadedon library:
http://code.google.com/p/tadedon/source/browse/tadedon-gwt-dev/src/main/java/com/xemantic/tadedon/gwt/dev/JettyLauncher.java

Yes, in 2016 it does, quite nicely indeed. :)
I launch Tomcat from within Eclipse, I launch GWT codeserver (SuperDev mode) from Eclipse, I launch Chrome from Eclipse.
You will find quite recent and very valuable set-up tutorials on Brandon Donnelson's YouTube channel: https://www.youtube.com/user/branflake2267/videos
What is essential for me is Eclipse debugger for GWT SuperDevMode: https://sdbg.github.io/
I prefer to have my project "mavenized", and there is lot of Maven archetypes also provided by Brandon: https://github.com/branflake2267/Archetypes/tree/master/archetypes
The official starting point (not just) for downloading the GPE plugin (not to confuse with above mentioned debugger plugin) is on GwtProject.com: http://www.gwtproject.org/download.html
For me personally GPE itself has become rather optional "convenience" component. (Yes, refactoring and auto-completion are nice to have, but that's all it is needed for. :)
It is not a one-click solution, and I prefer it like that, as those tend to be black-boxes prone to breaking.
And BTW make sure to take a look at GWT Material: http://gwtmaterialdesign.github.io/gwt-material-demo/
(Currently playing with 2.8-beta1.)

For Eclipse I use: m2eclipse plugin (1.0). It works well with one or two minor things. Also download the m2eclipse-extras plugin to add SVN functionality AND Maven (or CVS if you prefer).
When you download then your project it reads the pom.xml and [re]creates the Eclipse configuration files like the mvn eclipse:eclipse command.
For GWT... I've used it too. It's a pretty twiked configuration but it works. I use GWT 2.0.3, the maven-gwt-plugin uses the dependencies to work (no ref to GWT SDK) and it can debug from Eclipse which is simply great.
You have to compile to a war directory (not the target/classes standard). But the details are in my work, so let me see it tomorrow and complete this answer :) Don't give up. It's a great thing to have GWT+Eclipse+Maven.
Edit: part of my configuration
<build>...
<outputDirectory>war/WEB-INF/classes</outputDirectory>
...
</build>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<gwtVersion>${gwt.version}</gwtVersion> <!-- para forzar que use el de maven y no el SDK instalado -->
<disableCastChecking>true</disableCastChecking>
<disableClassMetadata>true</disableClassMetadata>
<runTarget>/subscriber/listSubscribers.htm</runTarget>
<webappDirectory>${basedir}/war</webappDirectory>
<soyc>true</soyc>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- dont know/remember if the jetty inside the gwt uses this... but it doesnt hurt-->
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.14</version>
<configuration>
<webAppConfig>
<contextPath>/magazine</contextPath>
<baseResource implementation="org.mortbay.resource.ResourceCollection">
<resourcesAsCSV>
${basedir}/src/main/webapp,
${basedir}/war
</resourcesAsCSV>
</baseResource>
</webAppConfig>
<connectors>
<connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
<port>8888</port>
<maxIdleTime>60000</maxIdleTime>
</connector>
</connectors>
<scanIntervalSeconds>3</scanIntervalSeconds>
<scanTargets>
<scanTarget>${basedir}/war</scanTarget>
</scanTargets>
</configuration>
</plugin>
AND
For debugging I create two tasks:
1) maven build inside eclipse that runs two goals: war:exploded gwt:debug
The first one copies all the resources into war directory for gwt debug to use them.
Next the gwt is ready.
Maybe you need to execute gwt:compile for the first time
2) a Java Remote Application debug configuration, with your project selected.
You run this configuration when the gwt:debug is "listening at port 8000"
AND: this is in a parent pom.xml (sorry I'll edit this post later :)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1-alpha-2</version>
<configuration>
<warSourceDirectory>${basedir}/src/main/webapp</warSourceDirectory>
<webappDirectory>${basedir}/war</webappDirectory>
<warName>${artifactId}</warName>
</configuration>
</plugin>

helios wrote good explanation. But it's not actual at the moment. So I advice you to try my modern example of EAR application running on GlassFish and with full debug support.

Preprocessing source code as a part of a maven build

I have a lot of Java source code that requires custom pre-processing. I'd like rid of it but that's not feasible right now so I'm stuck with it. Given that I have an unfortunate problem that shouldn't have existed in the first place, how do I solve it using maven?
(For the full story, I'm replacing a python-based build system with a maven one, so one improvement at a time please. Fixing the non-standard source code is harder, and will come later.)
Is it possible using any existing Maven plugins to actually alter the source files during compile time? (Obviously leaving the original, unprocessed code alone)
To be clear, by preprocessing I mean preprocessing in the same sense as antenna or a C compiler would preprocess the code, and by custom I mean that it's completely proprietary and looks nothing at all like C or antenna preprocessing.

There is a Java preprocessor with support of MAVEN: java-comment-preprocessor

This is something that is very doable and I've done something very similar in the past.
An example from a project of mine, where I used the antrun plug-in to execute an external program to process sources:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>process-sources</id>
<phase>process-sources</phase>
<configuration>
<tasks>
<!-- Put the code to run the program here -->
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note the tag where I indicate the phase where this is run. Documentation for the lifecycles in Maven is here. Another option is to actually write your own Maven plug-in that does this. It's a little more complex, but is also doable. You will still configure it similarly to what I have documented here.

Maven plugins can hook into the build process at pre-compile time yes, as for whether or not any existing ones will help I have no idea.
I wrote a maven plugin a couple of years ago as part of a university project though, and while the documentation was a bit lacking at the time, it wasn't too complicated. So you may look into rolling your own, there should be plenty of open source projects you can rip ideas or code from (ours was BSD-licenced for instance...)