Develop Reference

How to set different version for all child in a multi module maven project setup

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

add build tasks to maven pom project

An existing maven pom project <packaging>pom</packaging> which currently collects and packages resources needs to be extended to validate some of the resources.
In the same project I created a java-source directory src/main/java and in there I created a small java class to validate some of the resources. In addition I configured the maven-compiler and exec-maven plugin in the pom.
The java class runs fine in the IDE but it fails when I do mvn clean install it fails because it cant find the compiled class file. This is because the compile/test-compile phase is not available for pom-packaged projects.
My questions are:
Can I modify the compiler plugin to execute (compile) in a different phase than the default compile-phase. (I tried with adding an execution tag but no success)
Why is the exec-maven plugin executed because this was defined in test phase, which according to the docs is not part of the pom-package.
Are there other possibilities to run this validation task in the pom?
Modifying the packaging from pom to jar is a political sub-optimal solution.

Yes, you can configure maven-compiler-plugin to run the compilation in the package phase of the pom packaging.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<goals>
<goal>java</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
<configuration>
<mainClass>com.example.validate.App</mainClass>
</configuration>
</plugin>
</plugins>
</build>

How can I speed up maven builds of JavaFX application?

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/

Maven changes the order of plugins of different profiles

I have a pom.xml where I define the same plugin (same groupId and artifactId, different execution :-) ) in two different profiles. The executions are defined in the same phase, so the order is calculated by the order from the xml:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>echo</groupId>
<artifactId>test</artifactId>
<name>echo-test</name>
<version>1.0.0</version>
<packaging>pom</packaging>
<profiles>
<profile>
<id>1st-profile</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>1st-antrun-echo</id>
<phase>test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>1st antrun plugin</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>2nd-profile</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>com.soebes.maven.plugins</groupId>
<artifactId>maven-echo-plugin</artifactId>
<version>0.1</version>
<executions>
<execution>
<id>1st-soebes-echo</id>
<phase>test</phase>
<goals>
<goal>echo</goal>
</goals>
<configuration>
<echos>
<echo>1st echo-plugin</echo>
</echos>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>2nd-antrun-echo</id>
<phase>test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>2nd antrun plugin</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
All the plugin executions are defined in the test phase, therefore I would expect the following order:
1st antrun plugin
1st echo-plugin
2nd antrun plugin
However, since the antrun-plugins are merged, I get this output:
1st echo-plugin
1st antrun plugin
2nd antrun plugin
This command explains why is this happening: mvn help:effective-pom
Is there any other solution to preserve the order other than to introduce a new phases? Our project is really big and this is a very simplified example.
Why is this limitation of maven to merge the plugins into one with multiple executions?

In my experience this is one of the biggest bugs in Maven. If you have more than one configuration for the same plugin in different profiles, the order is simply unpredictable. I even observed, that I had some plugin order in project B in a given phase, and as soon as some of the same plugins got a config in a parent project (not even in the same phase), the order was ruined.
There is an obviously falsely closed bug related to this at https://issues.apache.org/jira/browse/MNG-2258.
Possible workarounds
Try to shift some of the plugins to previous phase if possible
(prepare-test used for some of the plugins and test for the rest)
Try
to replace the functionality of multiple plugins with a
groovy-maven-plugin script (quite handy with the ant integration, and
you reach the list of the active profiles in the script)
Write your
own mojo and call the plugins in the correct order (See
https://github.com/TimMoore/mojo-executor)
Give a try to gradle. Maybe it fits your needs, and it comes with a lot of good things from Maven
I do not think that there is any more you can do right now.

Lifecycle phases in maven multi module build

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.