maven-javadoc-plugin target-directory of aggregated docs - maven

I have an issue concerning the target directory of aggregated javadocs.
What I have is:
A maven project containing several modules. It looks a bit like the one used as example here
Project
|-- directory_to_contain_docs/
|-- pom.xml
|-- Module1
| `-- pom.xml
|-- Module2
| `-- pom.xml
`-- Module3
`-- pom.xml
I can't get it done to make javadoc generate the documentation in the directory named "directory_to_contain_docs".
This is what I tried:
I call the generation with "mvn javadoc:aggregate". And this is a part of the pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.4</version>
<configuration>
<!-- Default configuration for all reports -->
<failOnError>false</failOnError>
<destDir>${basedir}/directory_to_contain_docs</destDir>
<!-- as there are lots of incorrectly documented sources -->
<additionalparam>-Xdoclint:none</additionalparam>
</configuration>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate</goal>
</goals>
<phase>site</phase>
<configuration>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The javadoc is always generated in {project}/target/site/apidocs, the generation creates the complete path given in destDir beneath that directory. I am looking for a way to have the whole docs somewhere else.
Is there a chance to achieve that?
Thanks,
Ishiido

Don't know why I did not see it... The missing link is
configuration/reportOutputDirectory.
It specifies the directory where the documentation is generated. It may be specified further by destDir.

Related

How to use checkstyle:check in a multi module project

I'm trying to use Maven Checkstyle plugin in a multi module project.
The default setting for <sourceDirectories> (where the plugin to start looking for code) is ${project.compileSourceRoots}. This resolves to [C:\workspace\projectname\src\main\java] in my case, i.e. a List<String>.
Now, that default path is of no value to me, since my code resides in different places, like so: [C:\workspaces\projectname\module1\src\main\java]. Hence, I need to change <sourceDirectories> to a list of directories where my code actually is.
So far, so good...
The problem is that <sourceDirectories> expects a List<String>. I tried the following:
<sourceDirectories>
<sourceDirectory>pathToCode1</sourceDirectory>
<sourceDirectory>pathToCode2</sourceDirectory>
</sourceDirectories>
... but that didn't work. It will take the default path. (Moreover, <sourceDirectory> is deprecated!)
Having only one <sourceDirectory> (without the surrounding <sourceDirectories>) does work, but <sourceDirectory> only takes one path and you can't have more than one <sourceDirectory>. So, no cigar. Also, keep in mind <sourceDirectory> is deprecated.
I also tried various other methods of providing a List<String> to <sourceDirectories>, but alas, no progress. Here are some examples:
<sourceDirectories>[pathToCode]</sourceDirectories>
<sourceDirectories>pathToCode</sourceDirectories>
<sourceDirectories>{pathToCode}</sourceDirectories>
<sourceDirectories>{[pathToCode]}</sourceDirectories>
<sourceDirectories>{{pathToCode}}</sourceDirectories>
<sourceDirectories>{{{pathToCode}}}</sourceDirectories>
Is there another way of (directly, without "sub-tags") providing a List<String> to maven?
Is the plugin broken?
Have I missed something?
Edits below
My project structure:
MyProject
|-- pom.xml <-- plugin runs fine here
|-- domain-module
| |-- src
| | `-- main
| | `-- com/example/hello...
| | |-- TheCode.java
| | `-- resources
| | |-- checkstyle.xml
| | `-- LICENSE.TXT
| `-- pom.xml
|-- poms
| |-- parent
| | `-- pom.xml <-- this is my parent pom
My parent pom
<dependencies>
<dependency>
<groupId>com.puppycrawl.tools</groupId>
<artifactId>checkstyle</artifactId>
<version>${checkstyle.version}</version>
</dependency>
</dependencies>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.16</version>
<dependencies>
<dependency>
<groupId>com.example.hello</groupId>
<artifactId>domain-module</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>validate</id>
<phase>validate</phase>
<configuration>
<configLocation>domain-module/src/main/resources/checkstyle.xml</configLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<failsOnError>false</failsOnError>
<failOnViolation>true</failOnViolation>
<violationSeverity>warning</violationSeverity>
<logViolationsToConsole>true</logViolationsToConsole>
<skip>false</skip>
</configuration>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
<...>
</build>
</pluginManagement>
</plugins>
Since version 2.13 the use of sourceDirectories is broken (https://issues.apache.org/jira/browse/MCHECKSTYLE-260).
With 2.12 it works. Andreas Dangel mentioned in Jira:
The configuration described here
Checkstyle - Exclude folder
still works. Then the exclusion happens in checkstyle, rather than in
maven-checkstyle-plugin.

maven-war-plugin ignores <archiveClasses>

The <archiveClasses> option has no effect.
Running mvn clean compile war:exploded produces a war directory with .class files in the classes directory, and they are not archived into a jar in the lib directory neither. war:war produces same result.
Plugin configuration:
...
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<archiveClasses>true</archiveClasses>
</configuration>
</plugin>
...
Workarounds?
Maven version 3.3.3, maven-war-plugin version 2.6.
JIRA ticket – https://issues.apache.org/jira/browse/MWAR-355
This is the project in question: https://bitbucket.org/dmos62/raudondvaris
The first thing is you should move the plain configuration into a pluginManagement block like this:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<archiveClasses>true</archiveClasses>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
If you do the above the classes will be created within the war archive by using: mvn clean compile war:war
~/ws-git/so-questions/so-5 (master)$ unzip -t target/web-1.0.0-SNAPSHOT.war
Archive: target/web-1.0.0-SNAPSHOT.war
testing: META-INF/ OK
testing: META-INF/MANIFEST.MF OK
testing: WEB-INF/ OK
testing: WEB-INF/classes/ OK
testing: WEB-INF/lib/ OK
testing: WEB-INF/lib/commons-fileupload-1.1.1.jar OK
testing: WEB-INF/lib/commons-io-1.1.jar OK
testing: WEB-INF/lib/web-1.0.0-SNAPSHOT.jar OK
testing: WEB-INF/web.xml OK
testing: META-INF/maven/com.soebes.examples.so/web/pom.xml OK
testing: META-INF/maven/com.soebes.examples.so/web/pom.properties OK
testing: META-INF/INDEX.LIST OK
No errors detected in compressed data of target/web-1.0.0-SNAPSHOT.war.
This will also working for your call mvn clean compile war:exploded.
└── web-1.0.0-SNAPSHOT
├── META-INF
└── WEB-INF
├── classes
├── lib
│   ├── commons-fileupload-1.1.1.jar
│   ├── commons-io-1.1.jar
│   └── web-1.0.0-SNAPSHOT.jar
└── web.xml
The reason for this behaviour is simply cause by using a goal like war:war, or war:exploded there will be no life cycle started which means the configuration in the pom is not taken into account. If you like having a configuration for your command line calls you can do this by using a special configuration for command line calls like this (The id default-cli is the important part):
<project>
<build>
<plugins>
<plugin>
<groupId...>
<artifactId...>
<executions>
<execution>
<id>default-cli</id>
<configuration>
.....
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
which means having a special configuration for command line calls. Starting with Maven 3.3.1 it is possible having more than one configuration for command line calls by using it like:
<project...>
<build>
<plugins>
<plugin>
<groupId>...</groupId>
<artifactId>...</artifactId>
<executions>
<execution>
<id>first-cli</id>
<configuration>
....
</configuration>
</execution>
<execution>
<id>second-cli</id>
<configuration>
....
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
This can be used by maven via the following:
mvn plugin:goal#second-cli
mvn plugin:goal#first-cli
See also the release notes for Maven 3.3.1.

How to manage multiple profiles in Jhipster

Taken by example the jhipster-sample-app how can I manage multiple profiles, given that the same application will be installed in several machines having different configurations?
Since the deployment will be made using the apache tomcat, and it could be running one or more jhipster based apps, I would like to avoid using
-Dspring.profiles.active=MY_PROFILE
in the JAVA_OPTS variable.
Also it could happen to run the same application with different profiles on the same tomcat instance.
Taking profiles for the configuration of an application to support different environments like dev, test, prod is a bad idea.
Let us assume you have defined to make it simple three profiles like dev,test,prod. So now you build for dev environment like this:
mvn -Pdev clean package
Ok now you can take your artifact and deploy it. Next time you need for test environment you have to go like this:
mvn -Ptest clean package
You can take your artifact and deploy it. But what happens if you like to create for two environments or for three?
mvn -Pdev,test,prod clean package
This will usually fail, cause it's really tricky (and in same areas impossible) to handle different profiles to produce three different artifacts. So the best practice is to remove profiles and let your build produce just by:
mvn clean package
all the packages you need one for dev, one for test and one for prod.
One solution is to create a project structure like this:
.
|-- pom.xml
`-- src
|-- main
| |-- java
| |-- resources
| |-- environment
| | |-- test
| | | `-- database.properties
| | |-- qa
| | | `-- database.properties
| | `-- production
| | `-- database.properties
| `-- webapp
The different folders and property files are place holders just to show the path.
Next you need an assembly-descriptor one for each environment like this:
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
<id>test</id>
<formats>
<format>war</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<unpack>true</unpack>
<useProjectArtifact>true</useProjectArtifact>
</dependencySet>
</dependencySets>
<fileSets>
<fileSet>
<outputDirectory>WEB-INF</outputDirectory>
<directory>${basedir}/src/main/environment/test/</directory>
<includes>
<include>**</include>
</includes>
</fileSet>
</fileSets>
</assembly>
And finally you need to configure the maven-assembly-plugin like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>test</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<descriptor>${project.basedir}/src/main/assembly/test.xml</descriptor>
</descriptors>
</configuration>
</execution>
<execution>
<id>qa</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<descriptor>${project.basedir}/src/main/assembly/qa.xml</descriptor>
</descriptors>
</configuration>
</execution>
<execution>
<id>production</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<descriptor>${project.basedir}/src/main/assembly/production.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
In the end this will produce the following artifacts: artifact-VERSION-dev.war, artifact-VERSION-test.war and artifact-VERSION-prod.war with a single call of Maven. If you take a deeper look into that blog article the above can made much more elegant.

How to compile resources folder with Maven command

I'm using mvn compile to compile my Maven webapp. This project has a resources folder instead of the java folder created for a .jar project. My problem is that mvn finds no sources, and I haven't find a way in the maven docs to proceed this way. Is there a way, either by mvn command options or by pom.xml modification to make mav aware of the resources folder and compile it?
I know changing the name from resources to java makes the deal, but that's a spureous way to proceed.
To include additional source directories in your project you can use the Build Helper Maven Plugin
So for example the following configuration will add the src/main/resources folder of your project as a source folder.
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/src/main/resource</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Look at your .classpath file. That should have what folders including src and test are added. You can then add additional resources. I would normally use the IDE to look at the build path and add/exclude resources.

maven sources plugin includes configuration

I have a maven project with a non standard configuration:
$> tree
.
├── pom.xml
├── symbolic-link-to-sources -> ../src
└── target
├── maven-archiver
│   └── pom.properties
├── project-1.0-SNAPSHOT-sources.jar
├── project-1.0-SNAPSHOT.jar
└── surefire
I am trying to generate the sources jar of this maven module, whose sources are in ../src. I created a symbolic link to ../src in the case the plugin does not accept parent folders in paths. To do so I use the maven source plugin configured like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.2.1</version>
<configuration>
<includePom>true</includePom>
<includes>
<include>symbolic-link-to-sources/**</include>
</includes>
</configuration>
</plugin>
I run this plugin with mvn source:jar. Unfortunately I get only pom.xml in my sources jar. If I set includePom to false the plugin does not create the source archive.
I tried a lot of things as <include>: ../src, ../src/**, ../**, symbolic-link-to-sources, symbolic-link-to-sources/**, ../**/*.java none of them get me my sources into my sources jar. Although the documentation about it say its a relative fileset pattern.
Any idea how to get the content the java files of the ../src folder into my sources jar?
(Yes my symbolic link is not broken, no there is no way to rearrange my modules to have a standard folder hierarchy, this is a wrapper project around an ant based project).
You would use the <includes property to specify files/patterns to include within the source folder.
Have you set <sourceDirectory> to the correct location of the source (symbolic link and so on)? If so, can you omit the entire plugin configuration above and just run mvn source:jar on the pom? It should generate the sources correctly.
Stuck with the same problem and after googling and trying finally came to this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>../common/src/main/java</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Where "../common/src/main/java" is a path to sources that are linked as symbolic link in the current project.
Please note that build-helper-maven-plugin has package phase. With phase generate-sources I was getting "duplicate class" since the same sources were added from the symbolic link dir and from the dir configured in build-helper-maven-plugin.

Resources