1

I have a multi-module maven project, and would like to deploy only 2 sub modules:

pom.xml // parent pom
module1
--pom.xml
module2
--pom.xml
module3
--pom.xml

only module1.jar and module2.jar should be deployed.

Bionix1441
  • 2,135
  • 1
  • 30
  • 65
  • 1
    Wrong way cause a multi module is intended to get deployed/released together. – khmarbaise Aug 24 '20 at 19:23
  • I see... Thank you for the clarification. It should be splitted then – Bionix1441 Aug 24 '20 at 19:33
  • The question is why you want to deploy only two modules of all ? Unrelated to other modules? – khmarbaise Aug 24 '20 at 20:51
  • Only submodules of the projects war files are relevant for the application to run on the wildfly server. The others are not relevant. – Bionix1441 Aug 26 '20 at 11:08
  • That simply not a reason. Those modules can simply being deployed into a repository manager and you can only use the war file to deploy on wildfly. – khmarbaise Aug 26 '20 at 17:05
  • The simplest solution is to keep the structure and deploy the "not relevant" parts into a repository manager. And deploy only the war to wildfly. You could make a configuration in the "non relevant" modules and "skip" the deployment" but that more configuration than needed... – khmarbaise Aug 26 '20 at 17:07

2 Answers2

8

I have found the solution in the following question:

How to Deploy only the sub-modules using maven deploy?

The following property should be added to the pom.xml set to true for the modules that should not be deployed:

 <properties>
     <maven.deploy.skip>true</maven.deploy.skip>
 </properties>
Matthias Ngeo
  • 35
  • 6
Bionix1441
  • 2,135
  • 1
  • 30
  • 65
1

From my personal experience, we had a multi maven project. Where many modules was features that some clients had it and some other clients dint had them. For example when we build for 'clientA' we wanted Jenkins to package 'module1', 'module2' and 'module3' but when we build for 'clientB' we wanted only to package 'module1' and 'module2' to just give him the base functionality.

So, its not absolutely wrong to deploy/release part of a multi module project. In the above example there are a case where you need to build some of the modules and a case where you want to build all the modules. In those cases you can do that with profiles.

Example: in parent pom.xml

    <profiles>
        <profile>
            <id>base-functionality</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <modules>
                <module>/module1</module>
                <module>/module2</module>
            </modules>
        </profile>
        <profile>
            <id>new-feature</id>
            <activation>
                <activeByDefault>false</activeByDefault>
            </activation>
            <modules>
                <module>/module3</module>
            </modules>
        </profile>
    </profiles>

and then on Jenkins job for "clientA":

clean package -Pbase-functionality,new-feature

where on Jenkins job for 'clientB':

clean package -Pbase-functionality

Note: as khmarbaise stated on comment below this approach has same pitfalls and should be avoided if possible.

BadHumor
  • 76
  • 4
  • I strongly discourage that. https://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/ – khmarbaise Aug 26 '20 at 17:05
  • khmarbaise, I agree with you on that. messing with maven profiles should be as much simple cases as possible to avoid falling on pitfalls. Edited my comment to make it clear that this should be avoided if possible. – BadHumor Aug 27 '20 at 15:40
  • The problem is not the usage profiles here. The problem is that will produce issues with release and afterwards using tools (release plugin/versions plugin etc.) Yes profiles as well... – khmarbaise Aug 29 '20 at 10:41