I have a maven config file that triggers autogeneration of xsd and wsdl classes as follows:
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-xjc-plugin</artifactId>
<version>${cxf-xjc-plugin}</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${project.build.directory}/generated/src/main/java</sourceRoot>
<xsdOptions>
//xsds, wsdls etc
</xsdOptions>
</configuration>
<goals>
<goal>xsdtojava</goal>
</goals>
</execution>
</executions>
</plugin>
The generated classes go to: target/generated/src/main/java.
Problem: running 'mvn clean package' will always remove those classes. How can I prevent it? Is it possible having clean remove the full content of the target directory apart from the generated/ one?
It is possible not to delete some directory using maven-clean-plugin but this is definitely not a good idea:
it goes against Maven conventions
it forces you to change your POM everytime you want those classes to be generated
Solution to your exact question (NOT RECOMMENDED)
You can exclude directories with the maven-clean-plugin using excludeDefaultDirectories and filesets parameters:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.6.1</version>
<configuration>
<excludeDefaultDirectories>true</excludeDefaultDirectories>
<filesets>
<fileset>
<directory>${project.build.directory}</directory>
<excludes>
<exclude>generated/*</exclude>
</excludes>
</fileset>
</filesets>
</configuration>
</plugin>
Note that I strongly urge you NOT to use this solution.
Proposed solution
Your actual problem is not to re-generate the classes everytime you build because it takes a lot of time. The goal is then to avoid generation by using a custom profile:
<profiles>
<profile>
<id>noGenerate</id>
<properties>
<xjc.generate>none</xjc.generate>
</properties>
</profile>
<profile>
<id>generate</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<xjc.generate>generate-sources</xjc.generate>
</properties>
</profile>
</profiles>
With the following plugin definition:
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-xjc-plugin</artifactId>
<version>${cxf-xjc-plugin}</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>${xjc.generate}</phase>
<configuration>
<sourceRoot>${project.build.directory}/generated/src/main/java</sourceRoot>
<xsdOptions>
//xsds, wsdls etc
</xsdOptions>
</configuration>
<goals>
<goal>xsdtojava</goal>
</goals>
</execution>
</executions>
</plugin>
It seems cxf-xjc-plugin does not have any skip parameter so we have to resort to setting the phase to none when we want to avoid execution (this is an undocumented feature but it works).
The trick is to define two profiles: one, activated by default, sets a property telling the cxf-xjc-plugin to execute in the generate-soures phase, while the other one sets a property telling the cxf-xjc-plugin not to execute.
As such, when you want to classes to be generated, you can invoke Maven with mvn clean install and when you want the classes not to be generated, you can invoke Maven with mvn clean install -PnoGenerate.
The real gain and advantage here is that you do not need to change your POM everytime you decide to generate or not the classes.
I would have another approach.
1st) Configure your xjc plug-in to not erase any files i.e.:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<clearOutputDir>false</clearOutputDir>
<outputDirectory>${project.build.directory}</outputDirectory>
<sources>
<source> [any xsd] </source>
</sources>
</configuration>
2nd) Use maven-clean-plugin to clean jxc class generated dir in clean stage:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<filesets>
<fileset>
<directory>${basedir}/generated/src/main/java/...where the generated classes are</directory>
<includes>
<include>**/*.java</include>
</includes>
<followSymlinks>false</followSymlinks>
</fileset>
</filesets>
</configuration>
This works for me and I hope would be useful.
Related
I have created a multi-module project in maven which is as follows:
root/pom.xml
|________client/pom.xml
|________/src/main/java
|________/src/main/resources
|________common/pom.xml
|________/src/main/java
|________tools/pom.xml
|________/src/main/java
|________server/pom.xml
|________/src/main/java
|________/src/main/resources
I would like to compile the "client" module code which depends on ALL java classes in "common" module but on SOME java classes in the "tools" module.
Using the build-helper-maven-plugin as below, I was able to add all java source files under common/ path, but I need a way to define individual java files as sources which are under tools/.
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>../common/src/main/java</source>
<!-- Adding single java files as below does not work -->
<source>../tools/log/Log.java</source>
<source>../tools/socket/SocketClient.java</source>
<!----------------------------------------------------->
</sources>
</configuration>
</execution>
</executions>
You should include module "common" and "tools" as dependency in "client"
Then you can run build in the root of project: mvn clean install - it will build all modules.
Don't try to use parts of a module as dependency. Maven does not support this and it results in brittle and hard to maintain constructions.
If you only need parts of tools, then this is a clear signal that tools is too large and you need to split it up into two modules.
Ok, based on the comments received it seems that the ideal solution is to break the modules into sub-modules and use those as dependencies. However, as this is currently a time consuming task, I am posting a quick and dirty solution on how you can include one or more java files into your build by copying the files under a new source directory, src/main/external, and then add this directory as part of your sources.
<build>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>copy-source-java-files</id>
<phase>generate-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>src/main/external</outputDirectory>
<overwrite>true</overwrite>
<resources>
<resource>
<!-- External source directory -->
<directory>../tools/src/main/java/</directory>
<includes>
<!-- Files to be copied along with their directory paths -->
<include>tools/log/Log.java</include>
<include>tools/socket/SocketClient.java</include>
<include>tools/client/reader/**</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/main/java</source>
<source>src/main/resources</source>
<source>../common/src/main/java</source>
<!-- Here we add the source with the files copied -->
<source>src/main/external</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The output after compilation would be as follows:
root/pom.xml
|________client/pom.xml
|________/src/main/java
|________/src/main/resources
|________/src/main/external <----- This contains all external java files.
Disclaimer: I have solved this problem and am documenting the solution for the world to know.
How do I create and install a *-sources.jar containing "delomboked" source code in maven?
By default, The maven-source-plugin creates a sources jar without delomboking the source files, which causes projects that depend on the library binaries to complain about mismatching source files.
TL;DR (explained beneath)
Add the following plugins configuration to your plugins configuration in the project.build element of your pom.xml
<project>
...
<build>
<plugins>
...
<plugin>
<groupId>org.projectlombok</groupId>
<artifactId>lombok-maven-plugin</artifactId>
<version>1.18.0.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>delombok</goal>
</goals>
</execution>
</executions>
<configuration>
<sourceDirectory>src/main/java</sourceDirectory>
<outputDirectory>${project.build.directory}/delombok</outputDirectory>
<addOutputDirectory>false</addOutputDirectory>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>copy-to-lombok-build</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>${project.basedir}/src/main/resources</directory>
</resource>
</resources>
<outputDirectory>${project.build.directory}/delombok</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>generate-delomboked-sources-jar</id>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<jar destfile="${project.build.directory}/${project.build.finalName}-sources.jar"
basedir="${project.build.directory}/delombok"/>
</target>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>install-source-jar</id>
<goals>
<goal>install-file</goal>
</goals>
<phase>install</phase>
<configuration>
<file>${project.build.directory}/${project.build.finalName}-sources.jar</file>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<classifier>sources</classifier>
<generatePom>true</generatePom>
<pomFile>${project.basedir}/pom.xml</pomFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Explanation
lombok-maven-plugin will enable you to delombok the source code (${project.basedir}/src/main/java) and place it in the target directory (${project.build.directory}/delombok). Usually this will place the code in the ${project.build.directory}/generated-sources/delombok folder, but because Intellij automatically considers this additional source-code, duplicate code errors will occur when developing your library, in order to stop this, just specify a non-default target directory (in this case just outside of the generated-sources dir).
maven-resources-plugin is necessary in order to also copy resources from the standard ${project.basedir}/src/main/resources directory. If there are any other non-standard resource directories in your project, you should configure them in the resources section for this plugin.
maven-antrun-plugin is used instead of the maven-source-plugin because you cannot specify a custom source directory in the latter. The jar task points to our custom "generated-sources" and produces the standard-named sources jar.
maven-install-plugin install-file goal is used because you cannot attach jars using the install goal. We can hack a solution by manually installing a file using the install-file goal with a classifier of sources.
I hope this helps others who are on struggle street like I was with this problem.
The following solution is based on the one offered above but improves it by using the build-helper plugin to attach the generated delomboked source jar instead of using install-file. This has the benefit that the normal maven install and deploy phases correctly handle the generated file just as they would if the sources plugin had been used.
<project>
...
<build>
<plugins>
...
<plugin>
<groupId>org.projectlombok</groupId>
<artifactId>lombok-maven-plugin</artifactId>
<version>1.18.12.0</version>
<executions>
<execution>
<id>delombok-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>delombok</goal>
</goals>
<configuration>
<sourceDirectory>src/main/java</sourceDirectory>
<outputDirectory>${project.build.directory}/delombok</outputDirectory>
<addOutputDirectory>false</addOutputDirectory>
<encoding>UTF-8</encoding>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>generate-delomboked-sources-jar</id>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<jar destfile="${project.build.directory}/${project.build.finalName}-sources.jar"
basedir="${project.build.directory}/delombok"/>
</target>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>attach-delomboked-sources-jar</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${project.build.directory}/${project.build.finalName}-sources.jar</file>
<type>jar</type>
<classifier>sources</classifier>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Would like to point out that a profile can also be used (to get around the build source directory being un-customizable). The solution is described at https://sudonull.com/post/1197-Lombok-sourcesjar-and-convenient-debug
Add the following to the pom.xml
properties:
<origSourceDir>${project.basedir}/src/main/java</origSourceDir>
<sourceDir>${origSourceDir}</sourceDir>
<delombokedSourceDir>${project.build.directory}/delombok</delombokedSourceDir>
</properties>
Profile and build section changes:
<profiles>
<profile>
<id>build</id>
<properties>
<sourceDir>${delombokedSourceDir}</sourceDir>
</properties>
</profile>
</profiles>
<build>
<sourceDirectory>${sourceDir}</sourceDirectory>
<plugins>
<plugin>
<groupId>org.projectlombok</groupId>
<artifactId>lombok-maven-plugin</artifactId>
<version>1.18.20.0</version>
<executions>
<execution>
<id>delombok</id>
<phase>generate-sources</phase>
<goals>
<goal>delombok</goal>
</goals>
<configuration>
<addOutputDirectory>false</addOutputDirectory>
<sourceDirectory>${origSourceDir}</sourceDirectory>
<outputDirectory>${delombokedSourceDir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Execute with mvn clean install -Pbuild
This should solve the "Library source does not match the bytecode for class" error in IntelliJ and allow seamless debugging in most cases.
Ref: "Delombok plugin + profile in maven"
Both of the answers are flawed for multi-module projects or pure pom projects, because there are no sources, so you will have to create an empty directory, and it'll produce an empty .jar.
There is a simple (but a bit more complex) way to achieve functionality you want: make your own Maven Plugin.
Sounds overly complicated, but we can re-use maven-sources-plugin and with MOJO's inheritance update necessary parts:
import java.util.List;
import java.util.stream.Collectors;
import org.apache.maven.plugins.annotations.LifecyclePhase;
import org.apache.maven.plugins.annotations.Mojo;
import org.apache.maven.plugins.annotations.Parameter;
import org.apache.maven.plugins.source.SourceJarNoForkMojo;
import org.apache.maven.project.MavenProject;
/**
* This goal bundles all the sources into a jar archive, but uses delomboked sources.
*/
#Mojo(name = "jar-no-fork", defaultPhase = LifecyclePhase.VERIFY, threadSafe = true)
public class EnhancedSourceJarNoForkMojo extends SourceJarNoForkMojo {
#Parameter(property = "<some-prefix>.useDelombokSources", defaultValue = "true")
protected boolean useDelombokSources;
#Parameter(property = "<some-prefix>.delombokSourcesLocation", defaultValue = "delombok")
protected String delombokSourcesLocation;
#Override
protected List<String> getSources(MavenProject p) {
// if user doesn't want delomboked sources, use default algorithm
List<String> sources = super.getSources(p);
if (!useDelombokSources) {
return sources;
}
// typically, sources' list will contain: [src/main/java, target/generated_sources].
// replace src/main/java if it's present with delombok-generated sources
String target = p.getBuild().getDirectory();
return super.getSources(p)
.stream()
.map(s -> s.endsWith("java") ? String.format("%s/%s", target, delombokSourcesLocation) : s)
.collect(Collectors.toList());
}
}
Gist with pom.xml routine is available here.
I have a Maven Java project in which I added to the pom:
<build>
....
<plugin>
<!-- adding second test source directory (just for integration tests) -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>${plugin.build-helper-maven-plugin.version}</version>
<executions>
<execution>
<id>add-integration-test-source</id>
<phase>generate-test-sources</phase>
<goals>
<goal>add-test-source</goal>
</goals>
<configuration>
<sources>
<source>src/integration-test/java</source>
</sources>
</configuration>
</execution>
<execution>
<id>add-integration-test-resource</id>
<phase>generate-test-resources</phase>
<goals>
<goal>add-test-resource</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>src/integration-test/resources</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</build>
InteliJ recognized my java and resource folders under integration-test as a code folder, but Eclipse doesn't.
Is there any way that eclipse adds these folders as code folders when the project is imported?
Try to right click on your folder in Project Explorer select Build Path option in context menu and later click Use as Source Folder in menu which appears after choosing Build Path.
I suggest not using your own directory layout with Maven since this will cause many problems and you always have to configure around it. Just stick to the standard.
Separate integration tests and unit tests not by their source folders, but by their name.
Put all tests in src/test/java. You don't have to configure anything at this point, this path is taken by default.
Call integration tests IT*.java and unit tests UT*.java.
They can be run separately because maven-surefire-plugin executes unit tests and maven-failsafe-plugin executed integration tests. You can define filename patterns for identifying the test classes.
You could also create profiles for running only UTs or only ITs.
<project>
<!-- ... -->
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.13</version>
<configuration>
<includes>
<include>**/UT*.java</include>
</includes>
<excludes>
<exclude>**/IT*.java</exclude>
</excludes>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.18</version>
<configuration>
<includes>
<include>**/IT*.java</include>
</includes>
</configuration>
<executions>
<execution>
<id>failsafe-integration-tests</id>
<phase>integration-test</phase>
<goals>
<goal>integration-test</goal>
</goals>
</execution>
</executions>
</plugin>
Further reading: http://tomaszdziurko.pl/2013/01/running-unit-tests-integration-tests-separately-maven-testng/
There is also a interesting article about the correct usage of integration tests here: http://zeroturnaround.com/rebellabs/the-correct-way-to-use-integration-tests-in-your-build-process/
I have a question concerning the Maven javadoc plugin in Apache Maven. My current configuration allows to create a complete new java doc of my maven project, if the install phase will be executed. If I called the command "mvn clean install", the java doc files will be deleted completly (to do this, I have customoized the Maven clean plugin). And during the install phase, the java doc files will be generated again!
Is there a way to customized the java doc plugin in that way, that only the changed java source code sections will be updated in the existing java doc? And not the complete java doc will be generated again?
My maven-javadoc-configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9</version>
<configuration>
<noqualifier>all</noqualifier>
<reportOutputDirectory>myJavaDocOutputDirectory</reportOutputDirectory>
</configuration>
<executions>
<execution>
<id>create-myjavadoc</id>
<phase>install</phase>
<goals>
<goal>javadoc</goal>
</goals>
</execution>
</executions>
</plugin>
My maven-clean-plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<filesets>
<fileset>
<directory>target</directory>
<includes>
<include>**/*</include>
</includes>
<followSymlinks>false</followSymlinks>
</fileset>
<fileset>
<directory>MySourcefolder</directory>
<includes>
<include>**/*</include>
</includes>
<followSymlinks>false</followSymlinks>
</fileset>
</filesets>
</configuration>
</plugin>
Maybe the JavaDoc must not be generated in a snapshot build - depending on your requirements. If so, add a profile for release or special builds, which includes the maven-javadoc-plugin configuration, and remove the plugin from your default build/plugins section. When you want to generate the JavaDoc run the profile with "mvn clean install -P <profile>". Otherwise just run "mvn clean install" to avoid the JavaDoc generation. Such a profile can look like this:
<profiles>
<profile>
<id>release-build</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9</version>
<configuration>
<noqualifier>all</noqualifier>
<reportOutputDirectory>myJavaDocOutputDirectory</reportOutputDirectory>
</configuration>
<executions>
<execution>
<id>create-myjavadoc</id>
<phase>install</phase>
<goals>
<goal>javadoc</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
You can run it with: "mvn clean install -P release-build"
Our application can be built for several application servers, and used in several environments.
Type of application server and target environment should be specified using Maven profiles. One and only one of each profile type should be present when compiling the code. All profiles cause execution of one or several mavent-antrun-plugin copy tasks in order to include correct setting files to the generated JAR.
Below is part of the pom.xml file. Part of AS profile "oracle" is included, as well as part of environment profile "development". The purpose is, that in order to create JAR which can be deployed to Oracle AS in development environment, the code is compiled using two profile switches mvn -P oracle,development
AS profiles have also other tasks (not shown below) which have to be executed before the environment profile tasks take place (that's the reason profiles have different phases).
My issue is, that Maven refuses to execute tasks in both of the selected profiles.
mvn -Poracle works just as it's supposed. So does mvn -Pdevelopment. However, mvn -Poracle,development results in execution of only the tasks in oracle profile. If all the tasks in oracle profile's antrun plugin are commented out, then the tasks in development profile do get executed.
My questions are:
* Why does Maven refuse to execute ant tasks in both of these profiles?
* Is there a way to fix this?
Combining the profiles (oracle-development, jboss-development etc.) is not an option for us, because this module is part of a bigger project and would require modifications to several other projects.
We use currently Maven 2.2.0.
<profile>
<id>oracle</id>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<copy .../>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
...jboss, glassfish profiles...
<profile>
<id>development</id>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<copy .../>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
...production, test profiles...
Add a unique execution id to each <execution>:
<profile>
<id>oracle</id>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>execution1</id>
<phase>validate</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>ORACLE</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>development</id>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>execution2</id>
<phase>compile</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>DEV</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
Tested working solution :) Without the <id> element, I guess that one <execution> overrides the other.