We Keep Coding

Automatic verification of JavaDoc with Maven

During refactoring it happens frequently that JavaDoc gets out-of-date. It describes method arguments which are not present any more or some new ones are missing, to give examples.
It would be fine, if there is a Maven-plugin which automatically checks the existing JavaDoc and stops the build if there are some kind of "JavaDoc-violations".
I've seen the Maven-JavaDoc-Plugin and maven-doccheck, but both seem only to be able fix existing JavaDoc automatically in case of violations instead of bailing some error or warning.
Does anyone know how if there is some Maven-plugin like this and how to archive this?

As far as I know this is currently not possible with the maven-javadoc-plugin. There is the javadoc:fix mojo for the JavaDoc plugin, but this automatically fixes problems.
I recently created a JIRA entry for this problem: MJAVADOC-374 (which is acutally a duplicate of MJAVADOC-314).
Update:
You can use Checkstyle to verify correct JavaDoc. The configuration options are described here. Use the maven-checkstyle-plugin and the check-Mojo to integrate this into your maven build.
An example maven configuration could look like this:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.15</version>
<configuration>
<logViolationsToConsole>true</logViolationsToConsole>
<checkstyleRules>
<module name="JavadocMethod">
<property name="scope" value="public"/>
<property name="allowUndeclaredRTE" value="true"/>
<property name="allowMissingParamTags" value="false"/>
</module>
</checkstyleRules>
</configuration>
</plugin>
</plugins>
</build>
...
</project>

Debug Arquillian tests in IntelliJ

I have Java EE project in which I use Arquillian tests with JUnit on JBoss 7 (Windows). Tests are working fine however I cannot debug them.
From what I've googled (https://community.jboss.org/wiki/WhyDontBreakPointsWorkWhenDebugging) I understand that Arquillian tests are being run in separate VM therefore IntelliJ cannot debug them. I need IntelliJ to connect to that machine remotely over socket but I dont know how to do it.
I found this thread: Debugging with Arquillian in IntelliJ - Managed Container However I dont know how to get it work.
Also I stepped over this thread: http://devnet.jetbrains.com/message/5253623?tstart=0 so I filled hopefully appropriet surefire part in my pom.xml but it didnt help:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.3</version>
<configuration>
<debugForkedProcess>true</debugForkedProcess>
<skip>false</skip>
</configuration>
</plugin>
Could anyone guild me please how to debug tests in such configuration?

First of all depend on the container type you are using - managed, remote or embedded. See also https://docs.jboss.org/author/display/ARQ/Containers. For the latter the tests are running in the same JVM and you can for example debug your test directly in the IDE.
The Surefire configuration is in this case not important, because you want to debug in your IDE (unless you are executing maven goals from within your IDE).
For managed and remote containers you need to debug the actual container. For this to wrok you have to pass the right JVM options to the remote container, so that you can open a remote debugging session. One way of doing this is via arquillian.xml:
http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<!-- Need to set the default protocol and use resource filtering, because of https://issues.jboss.org/browse/ARQ-579 -->
<defaultProtocol type="Servlet 3.0"/>
<engine>
<property name="deploymentExportPath">target/artifacts</property>
</engine>
<container qualifier="incontainer">
<configuration>
<property name="jbossHome">${jbossTargetDir}</property>
<property name="javaVmArguments">-Xmx1024m -XX:MaxPermSize=512m -Xnoagent -Djava.compiler=NONE -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005</property>
<property name="allowConnectingToRunningServer">true</property>
</configuration>
</container>
The important part in the example above being the javaVmArguments.

I can run Arqullian tests by either Maven or by IntelliJ. I use embedded container. The most important thing is to configure the JBoss home at arqullian.xml nor just at the Maven configuration to IntelliJ know where the JBoss home is.
<arquillian xmlns="http://jboss.org/schema/arquillian"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/schema/arquillian
http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<engine>
<property name="deploymentExportPath">testing/target/artifacts</property>
</engine>
<container qualifier="jbossas-managed" default="true">
<configuration>
<!-- JBoss embedded does not use this property
<property name="javaVmArguments">-java.util.logging.manager=org.jboss.logmanager.LogManager -Xmx512m -XX:MaxPermSize=256m -Djava.util.logging.manager=org.jboss.logmanager.LogManager</property>
-->
<property name="jbossHome">target/wildfly-8.1.0.Final</property>
<property name="modulePath">target/wildfly-8.1.0.Final/modules</property>
<property name="allowConnectingToRunningServer">true</property>
</configuration>
</container>
IMPORTANT for debugging and running test in IntelliJ:
From some reason you must specify the logging manager to be able run embedded JBoss. For Maven it is easy and you can set it to configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!-- Fork every test because it will launch a separate AS instance -->
<forkMode>always</forkMode>
<systemPropertyVariables>
<java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
</systemPropertyVariables>
<redirectTestOutputToFile>false</redirectTestOutputToFile>
</configuration>
</plugin>
But the IntelliJ does not care about these plugin configuration at Maven and you must set it directly at the test case configuration. I did not find better solution. The embedded container does not care about Java VM configuration in arqullian.xml.
Here is always possibility to debug throught remote debugging. I like to do it at IDE. For me it is more confortable way. When you want to enable remote debugging you must set configuration to JAVA_OPT for embedded container nor at arqullian.xml.

Filtering a Spring XML file from a dependent project

I have a project MyProject which has a dependency on configuration in another project, BaseProject. Inside BaseProject I have dependencies to many different projects like ErrorLogging, PerformanceLogging, etc... I want to be able to build the top level project (MyProject) and have it filter all the spring xml files in those projects that it has as dependencies. I'm not having any luck. I can see the beans but they are not being filtered. Some of the beans are being filtered with default filters defined in their own poms but non are using the filters from MyProject.
MyProject - This contains the filter files and imports the config from the other projects.
BaseProject - Has spring beans defined which require filtering.
ErrorLogging - Has spring beans defined which require filtering.
When I run a package from MyProject all the spring files are correctly extracted into the jar file but they still contain the property placeholder values ${error.logging.host} for example... The beans in MyProject are correctly filtered. The alternative to this is to define the beans in MyProject but there are about 10 of these projects which use BaseProject and it's beans and I do not want to have to redefine them across 10 seperate projects.
If anyone could shed any light on this issue it'd be great. Thanks
Edit :
To make this clearer, I have a spring beans xml definition inside of the project ErrorLogging called errors-config.xml which defines beans for connecting to databases. This just has place holders for the connection details which should be provided by the filter.properties file that is inside of MyProject.
errors-config.xml is imported as a resource into baseproject-config.xml which sits inside of the BaseProject. Base project and it's config file are imported to MyProject.
I then build MyProject using Maven and I would like the property placeholders inside of errors-config.xml to be replaced with the values in the filter.properties in MyProject. MyProject can successfully filter it's own files but not those of ErrorsLogging project. ErrorsLogging seems to pick up filters from it's own src/main/resources folder instead of that of MyProject.

You can achieve that by unpacking all the dependencies, filtering and packing again, the whole process depends on the structure of your project, for a basic configuration this may suffices:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-dependencies</id>
<!--unpack all the dependencies to the target of this project-->
<phase>initialize</phase>
<inherited>false</inherited>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeGroupIds>${pom.groupId}</includeGroupIds>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/${artifactId}</outputDirectory>
<includes>**/*.properties,**/*.xml</includes>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>${config.maven.plattform.resources}/assembly/zip.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>zip</id>
<phase>package</phase>
<inherited>true</inherited>
<goals>
<goal>assembly</goal>
</goals>
</execution>
</executions>
</plugin>
This should work as long as you have correctly defined the correct filtering of the resources (which takes places later and also uses the maven-resources-plugin).

You could use the PropertyOverrideConfigurer to override the initial properties.
For example, if you have the folowing datasource definition in errors-config.xml :
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
<property name="driverClass" value="${hibernate.driverClassName}" />
<property name="jdbcUrl" value="${hibernate.url}" />
<property name="user" value="${hibernate.username}" />
<property name="password" value="${hibernate.password}" />
</bean>
You can override the database connection properties in the MyProject context like this :
<bean id="propertyOverideConfigurer" class="org.springframework.beans.factory.config.PropertyOverrideConfigurer">
<property name="locations">
<list>
<value>filter.properties</value>
</list>
</property>
</bean>
And in the filter.properties file you need to specify the bean names and properties you wish to override :
datasource.driverClass = oracle.jdbc.driver.OracleDriver
datasource.jdbcUrl = jdbc:oracle:thin:#localhost:1521:xe
datasource.user = username
datasource.password = password
Hope this helps.

In the Eclipe PMD plugin, can I reference the standard ruleset files?

I would like my eclipse PMD plugin configuration to access the same standard ruleset files as the maven-pmd-plugin.
You can configure the maven pmd plugin to use a custom set of rule sets like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.5</version>
<configuration>
<rulesets>
<!-- Two rule sets that come bundled with PMD -->
<ruleset>/rulesets/braces.xml</ruleset>
<ruleset>/rulesets/naming.xml</ruleset>
<!-- Custom local file system rule set -->
<ruleset>d:\rulesets\strings.xml</ruleset>
<!-- Custom remote rule set accessed via a URL -->
<ruleset>http://localhost/design.xml</ruleset>
</rulesets>
</configuration>
</plugin>
but in the eclipse plugin you can only switch on / turn off individual rules or specify a single ruleset file. Is there perhaps a way that ruleset file can include several others? Or do I have to aggregate that file automatically from the rulesets I want to use?

You can include other rulesets in a PMD ruleset file, e.g.
<ruleset ...>
...
<rule ref="rulesets/basic.xml"/>
...
<rule ref="rulesets/strings.xml">
<exclude name="AvoidDuplicateLiterals"/>
</rule>
...
</ruleset>
This is actually an excerpt from our own ruleset file, so it is proven to work :-)
As you can see, you can exclude/include individual rules from your ruleset, or even reconfigure them. One caveat: you must not mix rules for different languages in a single ruleset. I.e. in our case, we had to create separate rulesets for Java and JSP.
I learned the tricks myself from this page.

How to instruct Maven to ignore my main/resources/persistence.xml in favor of test/...?

I have two persistence.xml files, for the sake of testing:
src/main/resources/META-INF/persistence.xml
src/test/resources/META-INF/persistence.xml
How to instruct Maven to ignore the first file during testing? Now it is not ignored since OpenEJB says:
ERROR - FAIL ... Finder: #PersistenceContext unitName has multiple matches:
unitName "abc" has 2 possible matches.

Check out the alternate descriptors functionality which is aimed at what you're trying to do.
Try this setup:
src/main/resources/META-INF/persistence.xml
src/main/resources/META-INF/test.persistence.xml
Then you can construct OpenEJB to prefer the test.persistence.xml file by setting the openejb.altdd.prefix System or InitialContext property to test
A different possible solution could be to override the persistence unit properties in the test. With that approach you could avoid the need for a second persistence.xml which can be nice as maintaining two can be a pain.
You can use the Maven approach, but be aware that per spec the persistence provider will only look (aka scan) for #Entity beans in the exact jar or directory where the persistence.xml is found. So be keenly aware that in Maven these are two different locations:
target/classes
target/test-classes
EDIT More details on the overriding capabilities
You can override any property in your test setup via either system properties or the initial context properties (this includes jndi.properties files). The format is:
<unit-name>.<property>=<value>
So for example with the following persistence.xml:
<persistence>
<persistence-unit name="movie-unit">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>movieDatabase</jta-data-source>
<non-jta-data-source>movieDatabaseUnmanaged</non-jta-data-source>
<properties>
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
<property name="hibernate.max_fetch_depth" value="3"/>
</properties>
</persistence-unit>
</persistence>
You can override and add persistence unit properties in your test case. There are currently no facilities for removing them (if you have a need for that let us know – it hasn't really come up so far).
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.openejb.client.LocalInitialContextFactory");
p.put("movie-unit.hibernate.hbm2ddl.auto", "update");
p.put("movie-unit.hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
context = new InitialContext(p);
Or alternatively via a jndi.properties file
java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory
movie-unit.hibernate.hbm2ddl.auto = update
movie-unit.hibernate.dialect = org.hibernate.dialect.HSQLDialect

I think you can create two profiles in your pom.xml:
<properties>
<environment>dev</environment>
</properties>
<profiles>
<profile>
<id>prod</id>
<properties>
<environment>test</environment>
</properties>
</profile>
</profiles>
After that, in your src folder, create two folders named dev/resoruces and test/resources and copy your different resources there. After that, add something like this:
<resources>
<resource>
<directory>${basedir}/src/main/resources</directory>
<filtering>false</filtering>
</resource>
<resource>
<directory>${basedir}/src/main/${environment}/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
The ${basedir} depends on the command line parameter, it can be test or dev.
You run the maven command like this: mvn clean package -P test.

I have been testing these and other similar solutions without involving the pom.xml... In my opinion, the best way to solve this issue is to have two application-context.xml (one only to be used in test classes) and to add a custom persistence unit manager bean in the test's application-context.xml. Like this example:
<bean id="pum" class="org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager">
<property name="persistenceXmlLocation">
<value>classpath*:META-INF/test.persistence.xml</value>
</property>
<property name="defaultDataSource" ref="dataSource"/>
</bean>
This solution runs.
:)

Better add both files - in general, making test/production or debug/profile/production distinction in build makes only trouble.
Better try to use different perasistence unit name for production (say abc-production) and for tests (abc-tests).