I have defined a maven multi modul build where one module is only used to generate sources. It will not compile, test or package and won't create any artifacts apart from the generate source files.
I haven't found a way yet to only execute the phases up to generate-sources on the generator module, regardless of the phase I specify when I start the multi module build. There are some solutions for skipping unwanted phases, but this is not a real option as there are just to many of them.
For those wondering, why I would want it: The build uses tycho and the fornax oaw plugin and so I had to split the build into two separate pom files and use a multi module build file to execute them "together".
After seeing your latest question I think I might have a solution for you.
I guess that all your ../projectN/generate/pom.xml has the top pom as its parent but I suggest that you create a special generate-parent pom with a special plugin management that will skip all the phases for you.
Create an extra folder called generate-parent at the top level:
<modules>
<module>../generate-parent/pom.xml</module> <!-- NEW FOLDER WITH POM -->
<module>../project1/generate/pom.xml</module>
<module>../project1/pom.xml</module>
<module>../project2/generate/pom.xml</module>
<module>../project2/pom.xml</module>
<!-- and many more projects with or without generate sub modules -->
</modules>
This new pom will inherit from the parent pom as usual but add only some extra plugin management:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>your-group</groupId>
<artifactId>your-parent-pom-artifact-id</artifactId>
<version>your-parent-version</version>
</parent>
<artifactId>generate-parent</artifactId>
<packaging>pom</packaging>
<name>${project.artifactId}-${project.version}</name>
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<id>default-resources</id>
<phase>none</phase>
</execution>
<execution>
<id>default-testResources</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<executions>
<execution>
<id>default-compile</id>
<phase>none</phase>
</execution>
<execution>
<id>default-testCompile</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.7.2</version>
<executions>
<execution>
<id>default-test</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>default-deploy</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
Now with this pom all the default phases are disabled.
Now use this pom in all the generate projekcts. The above pom inherits all of the good stuff you have in your parent pom but just adds these special plugin management parts that disables the phases after the generate-sources.
project1/generate/pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>your-group</groupId>
<artifactId>generate-parent</artifactId>
<version>your-parent-version</version>
<relativePath>../../generate-parent</relativePath>
</parent>
...
The rest of your pom
...
</project>
This will effectively do what you want, the generate-parent is the middle-man that adds all the plugin management you want for just these generate projects.
So far as I understand, this is about using Xtext to create a code generator that is invoked in a maven build. I think you need to split up your project a bit more. You only need the generator to be built, when you change your grammar. So it would be a good idea to have a independent project (not a module) that contains the generator. You build and deploy your generator to a maven repository. In your normal build you use the fornax-oaw-m2 plugin to generate your sources in the generate-sources phase as you are doing now. You just need to include the generator as a dependency for the fornax-oaw-m2 plugin.
EDIT:
So to come back to your multi module project you want to build: I suggest that there is a module that only contains the resources from which you generate the sources and nothing else. The other java sourcec should be contained in their own module. Then I can suggest two alternatives for using the generator:
Run the generator in the module that contains the resources from which you generate the sources and set relative paths appropriately
Run the generator in the module that should contain the generated sources and include the module with the resources as a dependency (you may need to unpack that dependency before generating resources)
You still always generate in the generate-sources phase. In the 2nd alternative, the configuration of the fornax-oaw-m2 plugin will be duplicated, if you need generate sources to a set of different modules. But I think that this is more the maven way, as you only change the project you are currently building. In the first alternative, you would have to declare the dependencies from the modules, where source is generated into to the module that does the source generation. This seems a bit awkward.
Related
I have many projects is my EAR , and we have configured maven for automated source generation for each projects using eclipse "external tools configurations" (org.eclipse.ui.externaltools.programLaunchConfigurationType).
But currently I have to go to "Run --> External Tools configuration" and run generate each sources manually one after another.
Is there any way I can automate this process, which will enable me to run these configurations one after another automatically ?
you can use multi module maven project and build project just by one click and then configure maven source generation as following
on parent pom use
<modelVersion>4.0.0</modelVersion>
<name> foo - root </name>
<groupId>com.foo</groupId>
<artifactId>bar</artifactId>
<version>3.0.9</version>
<packaging>pom</packaging>
on childeren
<parent>
<groupId>com.foo</groupId>
<artifactId>bar</artifactId>
<version>3.0.9</version>
</parent>
and finally for source generation
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>prepare-package</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
look at here and here
We have multi module project setup with a lot of dependencies on different modules versions.
ParentModule_16.3.0.1.0-
----ChildModule1_16.3.0.1.0
----ChildModule2_16.3.0.1.0
----ChildModule3_16.3.0.1.0
Earlier all versions were hardcoded in pom.xml for each module. Later we decided to get these versions from a property file. So i followed below link and it worked fine -
Maven: set property in pom.xml from properties file
now we have a scenario where we want to update version of
childmodule2_16.3.0.1.0 to childModule2_16.6.0.0.0
and
parentModule_16.3.0.1.0 to parentModule_16.6.0.0.0
and rest remains unchanged.
Now the issue we are facing is, when we do full build using parent's pom it doesn't pick jars of some modules because of old versions(16.3.0.1.0).
I have read some blogs where it says maven always pick latest versions.hence the older jars are not getting picked.and some says You always have to specify parent's version. Fortunately, it is inherited as the module's version what is desirable in most cases. Moreover, this parent's version declaration is bumped automatically by Maven Release Plugin.
Can some please help me to understand this. Is there any way to solve this? Thanks in advance.
Below is my Parent pom.xml
<modelVersion>4.0.0</modelVersion>
<groupId>com.myproject</groupId>
<artifactId>parent</artifactId>
<version>${parent-version}</version>
<packaging>pom</packaging>
<modules>
<module>chiled1</module>
<module>child2</module>
</modules>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>version.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.18.1</version>
<configuration>
<parallel>methods</parallel>
<threadCount>10</threadCount>
</configuration>
</plugin>
<!-- Make assembly -->
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<descriptor>${project.basedir}/assembly.xml</descriptor>
<outputDirectory>${project.basedir}/dist</outputDirectory>
</configuration>
<executions>
<execution>
<id>create-archive</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
child2 pom.xml
<groupId>com.myproject.child1</groupId>
<artifactId>child2</artifactId>
<version>${child2-version}</version>
<build>
<finalName>${project.artifactId}-${version}</finalName>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>../version.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
version.properties
Earlier -
parent-version=16.3.0.1.0
child1-version=16.3.0.1.0
child2-version=16.3.0.1.0
Now-
parent-version=16.5.0.0.0
child1-version=16.3.0.1.0
child2-version=16.5.0.0.0
I think you are doing something dangerous.
The problem is that if I didn't get you wrong you are trying to build only some of your libs with new versions and some with old ones. In Maven usually if something has a non-SNAPSHOT version it's treated as "released" and hereby stable and it wouldn't try to update that ever again. So this could describe your observation of old versions being used.
Usually you would have your project in a 3.0.1-SNAPSHOT and work with that. In this case you would always get your updates.
Now there are other problems with this approach. You can release a new version with each module having it's own version without any problems. The problem is if you try to release something with a version you already used, things will blow up. Now you could restrict your Maven reactor to release only the modules you want to release and would avoid this problem. Unfortunately you would be running into the next problem as Maven would only update the versions of modules that are part of the current build. So in this case any SNAPSHOT dependency to a module that's not being released would stay a SNAPSHOT and the release plugin would fail for this.
A few years ago I had a customer with the need to release individual modules just the way you are describing it. I did solve the problem, but it wasn't easy. In short: I had to patch the release plugin by changing one or two lines of code, then I had to create a Jenkins Plugin to assist me with configuring the build as it now required an insane input on the commandline. I wrote down everything about :
the release process here:
https://dev.c-ware.de/confluence/display/PUBLIC/Releasing+modules+of+a+multi-module+project+with+independent+version+numbers
the Jenkins Plugin here:
https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin
The code for the Jenkins plugin is located here:
https://github.com/chrisdutz/jenkins-release-plugin
I currently am using the Exec Maven Plugin and it works fine with:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<id>myExec</id>
<goals>
<goal>exec</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<executable>myExec</executable>
<arguments>
<argument>--foo=${basedir}/src/test/resources/test.xml</argument>
<argument>--output-directory=target/generated-sources/output</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
I am also using the build helper plugin as follows:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/output</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
This is incredibly verbose however and I want multiple maven modules to be able to use this program and not have to retype all the exec plugin specific XML along with the builder XML.
Question: How do I possibly combine these 2 into another plugin?
I have used the maven archetype generator to generate a sample maven plugin and have a Mojo class:
#Mojo(name = "touch", defaultPhase = LifecyclePhase.PROCESS_SOURCES)
public class MyMojo
extends AbstractMojo
{
public void execute()
throws MojoExecutionException
{
ExecMojo exec = new ExecMojo();
}
}
And have figured out how to create a new ExecMojo.
Question How do I add the arguments here as I would in the XML above? And how can I integrate these arguments into my plugin?
Instead of creating your own Maven plugin, which may reduce portability and maintenability of your project, you may consider the following approach instead:
Have a common parent pom
Configure the given plugins configuration, optionally in a Maven profile
In the concerned module, point to this parent. Optionally (in case of profiled configuration) activate it on demand when required.
A simple parent pom would look like the following:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.sample</groupId>
<artifactId>sample-maven-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<properties>
<path.to.myexec>path</path.to.myexec>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<id>myExec</id>
<goals>
<goal>exec</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<executable>${path.to.myexec}\myExec</executable>
<arguments>
<argument>--foo=${basedir}/src/test/resources/test.xml</argument>
<argument>--output-directory=${project.build.directory}/generated-sources/output</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/output</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>myexec-profile</id>
<build>
<plugins>
<!-- optionally move here the configuration above -->
</plugins>
</build>
</profile>
</profiles>
</project>
Note the path.to.myexec property I added, to be overriden in children projects if required, in order to point to the correct relative path.
Then, once installed in your machine (or deployed in your company Maven repository), it can be referenced as following in any concerned Maven projects:
<parent>
<groupId>com.sample</groupId>
<artifactId>sample-maven-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
No need to re-declare the plugin configurations above and its verbose approach. They will be automatically part of the defaul build as part of the inherited build configuration from this parent.
The profiled approach can also be a solution if:
You want to reuse an existing parent pom already used by projects which don't need this configuration
You don't always need this behavior on your build and you want to activate it on demand
In such a case, you can then activate it via, as an example:
mvn clean package -Pmyexec-profile
Given that you already set the parent accordingly and you moved into the profile the configuration above.
Advantages of this approach:
lighter option than writing a new maven plugin (which needs to be written, tested, maintained, distributed, etc.)
easier for consumer modules to customize something: at any moment they can override parent's configuration as an exception
less fragile: just imagine what if another version of one of these plugins provides a bug fix important for you, that's easy to configure an XML, much less easy to change the customized maven plugin etc.
configuration remains centralized, transparently accessible and entry point for further governance
easier troubleshooting: at any moment a consumer module can run mvn help: effective-pom and see the merged full effective pom (as aggregate of parent and current pom) and check what it's actually running
How to skip parent plugin executions in certain modules
A simple (and often used) approach to execute this plugins only in certain modules while having the parent in common with other modules is the following:
Define a new property, let's call it skip.script.generation, with default value to true, defined in the parent pom.
Use this skip property in the skip configuration entry of the plugins above.
Re-define the property only in the concerned modules and set it to false. This will be the only configuration required for their pom.xml files, hence reduced to one line (keeping verbosity really low).
The exec-maven-plugin provides such a skip option, unfortunately the build-helper-maven-plugin doesn't. But that's not blocking us. We can still skip the two executions playing with their phase element, setting it to a non existing phase, like none and as such skipping them. This is suitable because the two executions are actually already attached to the same phase, generate-sources.
For this approach, let's rename our new property to script.generation.phase.
As an example:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.sample</groupId>
<artifactId>sample-maven-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<properties>
<path.to.myexec>path</path.to.myexec>
<script.generation.phase>none</script.generation.phase>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<id>myExec</id>
<goals>
<goal>exec</goal>
</goals>
<phase>${script.generation.phase}</phase>
<configuration>
<executable>${path.to.myexec}\myExec</executable>
<arguments>
<argument>--foo=${basedir}/src/test/resources/test.xml</argument>
<argument>--output-directory=${project.build.directory}/generated-sources/output</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<phase>${script.generation.phase}</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/output</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>myexec-profile</id>
<build>
<plugins>
<!-- optionally move here the configuration above -->
</plugins>
</build>
</profile>
</profiles>
</project>
Note the <phase>${script.generation.phase}</phase> changes for both plugins. With its default value to none, this property is effectively disabling their executions by default.
In another module you would then have the following:
<parent>
<groupId>com.sample</groupId>
<artifactId>sample-maven-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<properties>
<script.generation.phase>generate-sources</script.generation.phase>
</properties>
And nothing else. That is. Maven during the build will re-define the property for a certain module and automatically replace it in the configuration inherited from its parent and as such enabling again the two executions above.
I have an original java webapp (that thus produces a WAR file) which is Maven-managed, let's call it webapp.
I like to keep its Maven configuration as it is, but at times I need to, say, post-produce that generated WAR by manipulating its contents (or anyway apply generic operations on it).
So I made a multimodule project:
- multimodule
+-- webapp
+-- operator
The operator could do several things. For instance, it calls a (Java) command line program that does some checks on a WAR: how do I take the 'webapp' module output (i.e. the WAR file) and set it as input of the operator module?
I have no clue on how to do this nor on what to search on the net, so I'm stuck.
You need to make webapp a dependency of the operator project.
Sample POM of operator:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<packaging>jar</packaging>
<version>0.0.1-SNAPSHOT</version>
<groupId>my-groupid</groupId>
<artifactId>operator</artifactId>
<dependencies>
<dependency>
<groupId>my-groupid</groupId>
<artifactId>webapp</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
</dependencies>
</project>
By creating an explicit dependency, Maven will build the webapp before the operator project in the reactor and you will be able to post-process that war.
Let's take an example by considering that you want to invoke a program taking this war as argument.
First, this new dependency has to be copied to a specific location. This is done with the maven-dependency-plugin. This plugin has a goal copy-dependencies which is used to copy all direct dependencies of a project to a location in the filesystem. Sample configuration would be:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/libs</outputDirectory>
</configuration>
</execution>
</executions>
<plugin>
Now that the dependency is available in the filesystem, you can run a program using the exec-maven-plugin. Sample configuration, launching operator -param1 webapp.war:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
</execution>
<configuration>
<executable>operator</executable>
<workingDirectory>${project.build.directory}/libs</workingDirectory>
<arguments>
<argument>-param1</argument>
<argument>webapp.war</argument>
</arguments>
</configuration>
</executions>
</plugin>
Take a look at maven profiles.
You should be able to define two profiles and configure second profile to do your additional operations. If you follow this approach, you won't need two modules.
My problem can be reproduced by creating a new project in Netbeans 8:
New Project >> Maven >> JavaFX Application
Then adding the org.springframework spring-context dependency.
Build times go up from a few seconds to more than half a minute, most of it due to running javafxpackager.
I can live with slow release builds but how can I speed up my development builds?
This is my pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org /2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>mavenproject1</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>mavenproject1</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<mainClass>com.mycompany.mavenproject1.MainApp</mainClass>
</properties>
<organization>
<!-- Used as the 'Vendor' for JNLP generation -->
<name>Your Organisation</name>
</organization>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>package</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<excludeScope>system</excludeScope>
<excludeGroupIds>junit,org.mockito,org.hamcrest</excludeGroupIds>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>package</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>${java.home}/../bin/javafxpackager</executable>
<arguments>
<argument>-createjar</argument>
<argument>-nocss2bin</argument>
<argument>-appclass</argument>
<argument>${mainClass}</argument>
<argument>-srcdir</argument>
<argument>${project.build.directory}/classes</argument>
<argument>-outdir</argument>
<argument>${project.build.directory}</argument>
<argument>-outfile</argument>
<argument>${project.build.finalName}.jar</argument>
</arguments>
</configuration>
</execution>
<execution>
<id>default-cli</id>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>${java.home}/bin/java</executable>
<commandlineArgs>${runfx.args}</commandlineArgs>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<compilerArguments>
<bootclasspath>${sun.boot.class.path}${path.separator}${java.home}/lib/jfxrt.jar</bootclasspath>
</compilerArguments>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.16</version>
<configuration>
<additionalClasspathElements>
<additionalClasspathElement>${java.home}/lib/jfxrt.jar</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.0.6.RELEASE</version>
</dependency>
</dependencies>
Thanks!
Daniel
You could define the plugin in a profile that is inactive by default. Then, in order to make the production build, you would have to manually specify the activation of that profile (or activate it in any other standard way).
You pom would be something like (only diffs shown):
<?xml version="1.0" encoding="UTF-8"?>
<project ...>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
...
<executions>
<!-- take this out of here
<execution>
<id>unpack-dependencies</id>
...
</execution>
-->
<execution>
...
</execution>
</executions>
</plugin>
...
</plugins>
</build>
<profiles>
<profile>
<id>javafxpackager</id>
<build>
<plugins>
<!-- INSERT THE exec-maven-plugin HERE, ONLY
WITH THE unpack-dependencies EXECUTION -->
</plugins>
</build>
</profile>
</profiles>
</project>
In production run mvn ... -Pjavafxpackager
To complete Nikos' answer, this is the configuration of the maven-assembly-plugin which creates the archive for normal builds.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<appendAssemblyId>false</appendAssemblyId>
<archive>
<manifest>
<mainClass>${mainClass}</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>my-assembly</id>
<phase>package</phase>
<goals>
<goal>assembly</goal>
</goals>
</execution>
</executions>
</plugin>
above solutions dont work. The problem has nothing to do with javafxpackager whatsoever. The cause lies in the maven standard configuration. On every project run Maven performs a project clean by default. This deletes the targets/classes/ folder. Thats the same folder where all the unpacked jar files of your dependencies are placed. If those get deleted on every new run then they have to be unpacked over and over again. Anyway, heres how you can prevent the clean from happening:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Add this to your POM.xml. Make sure you get the version correct You can check the version of your maven clean plugin in the effective pom (thats parent pom + project POM combined). In netbeans you can watch the readonly effective pom.xml under the effective tab when you've opened the pom.xml file of your project.
please give me a few +1's i want to get 50 points so that i can finally comment on other peoples answers. Thank you!
EDIT:
Also add skip to default-cli to avoid errors
<execution>
<id>default-cli</id>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<skip>true</skip>
<executable>${java.home}/bin/java</executable>
<commandlineArgs>${runfx.args}</commandlineArgs>
</configuration>
</execution>
EDIT 2:
For those of you who would like to retain the ability to clean heres another method to prevent the maven plugin from deleting all jar files:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<excludeDefaultDirectories>true</excludeDefaultDirectories>
<filesets>
<!-- delete directories that will be generated when you
start the develpment server/client in eclipse
-->
<fileset>
<directory>target/classes</directory>
<excludes>
<exclude>**/*</exclude>
</excludes>
</fileset>
</filesets>
</configuration>
Again, make sure is correct
TL;DR:
To avoid unpacking dependencies, you don't need to modify the default pom.xml at all. Just change what Netbeans calls when you press Run (or Debug). In nbactions.xml change:
runfx.args: Replace -jar "${project.build.directory}/${project.build.finalName}.jar" with -cp %classpath ${mainClass}. This way, the exec goal will not try to execute any jar but rather run your project from the target/classes directory. So no need to build the jar at all.
goals: replace the "package" goal with "process-classes" (or "test" or any phase you want). We don't need a jar so no need to run the package phase. And no package phase also means no unpacking/repacking etc.
If you ever need the jar file with all the dependencies, just choose "clean and build" in Netbeans or run mvn clean install.
Background:
What happens when you press run in the standard Netbeans JavaFX maven project is:
clean package exec - defined in nbactions.xml, configured in pom.xml:
clean: as usual - deletes the target directory
package:
first as usual - copies resources and compiles sources to target/classes and packs that all to a jar without dependencies
maven-dependency-plugin unpacks all the dependency jar files to target/classes
exec-maven-plugin:unpack-dependencies (the id "unpack-dependencies" is missleading, should be something like "jar-with-dependencies") executes javapackager which builds a jar with dependencies overwriting the first jar
exec:
executes java with ${runfx.args} as arguments (defined in nbactions.xml) i.e. runs the jar
What happens after the changes above:
clean process-classes exec - defined in nbactions.xml, configured in pom.xml:
clean: as usual - deletes the target directory
process-classes:
as usual - copies resources and compiles sources to target/classes
exec:
executes java with ${runfx.args} as arguments (defined in nbactions.xml) i.e. runs the class target/classes/path/to/your/MainClass
Even better:
You may want remove the "clean" goal from nbactions.xml. This way, all the resource files won't be copied each time over and over (although the resource plugin will still keep saying "Copying X resources" - see the comments under https://stackoverflow.com/a/33700970/3519572).
Now, you may also want to only recompile changed classes rather than the whole project by adding useIncrementalCompilation=false (e.g. like <goal>org.codehaus.mojo:exec-maven-plugin:1.2.1:exec -Dmaven.compiler.useIncrementalCompilation=false</goal>). But be sure to read https://stackoverflow.com/a/49700942/3519572!
Therefore, you may also want to add a toolbar button to the "clean" goal to be able to run it manually easily at any time: https://stackoverflow.com/a/26546551/3519572.
BTW:
Finally, you might want to change the NetBeans generated pom.xml anyway. At least my NB 8.2 refers to the deprecated javafxpackager (rename to javapackager). Also the part <bootclasspath>..../lib/jfxrt.jar</bootclasspath> doesn't seem to be necessary with java 8. It actually breaks my build if I run it from the terminal. Removing it seems to fix it and doesn't seem to cause any trouble if started from NB.
You can also use parallel maven build feature to speed up.
By default, Maven does not utilize the full power of your hardware. It builds all modules sequentially rather than in parallel. However, often your project setup does not require it to be sequential. Often you can command Maven to analyze your project including the dependency graph and build the project in parallel where possible. You can either specify the exact number of threads to use for building your project or use a portable version of the parameter and specify the number of thread in terms of CPUs available on the machine.
mvn -T 4 install -- will use 4 threads
mvn -T 1C install -- will use 1 thread per available CPU core
See for more details: https://zeroturnaround.com/rebellabs/your-maven-build-is-slow-speed-it-up/