29

Heyho,

I have a maven project with this scructure:

parent:

  • List item
  • API module
  • module2
  • ...
  • module5
  • test
  • distribution/assembly

So first i run the parent module, then I run the module which builds the api, then the modules which depend on the api, then a test module which contains tools to test and at the end I run a assembly/distribution where I package some modules in a archive. Because of some problems I can not really change the way and it works so far perfect.

With the jenkins I release it to the maven repo, but I want only to release for example the API, and a few modules, not the test module and the distribution module. Is there a way to skip them? Dont't want to release stuff I dont really need :/

maxammann
  • 1,018
  • 3
  • 11
  • 17
  • Is this a multi-module build ? Does you parent pom.xml have modules entries? Have the modules like API module a parent (the parent) ? – khmarbaise Jan 12 '13 at 18:02
  • yes, the multi-module setup works perfectly I just want to exclude modules from the maven repo :P – maxammann Jan 12 '13 at 19:08

3 Answers3

38

To understand you correctly, you still want to run the test modules, but your don't want to deploy/release them. The maven-deploy-plugin to the rescue! To artifact will still be built, but not deployed.

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-deploy-plugin</artifactId>
    <version>2.7</version>
    <configuration>
        <skip>true</skip>
    </configuration>
  </plugin>

However, the jenkins release plugin will still release all artifacts. Instead of using the jenkins release plugin, think about releasing with the maven-release-plugin, which is easy to do:

mvn release:prepare
mvn release:perform

Since the default goals are deploy and site, all should be ok.

Just make sure you have a scm tag in your root pom:

<scm>
    <connection>scm:svn|git:https://...</connection>
    <developerConnection>scm:svn|git:https://...</developerConnection>
</scm>

and that your versioning tool command (git, svn, ...) is available on the PATH.

ThomasRS
  • 8,215
  • 5
  • 33
  • 48
asgoth
  • 35,552
  • 12
  • 89
  • 98
  • I already tried this, but I think It's a problem with jenkins which releases all modules :/ – maxammann Jan 12 '13 at 22:06
  • k it would be possible with the "normal" deployment with the deploy plugin, but maybe not with the jenkins plugin :/ – maxammann Jan 12 '13 at 22:23
  • I think you should look into that. Jenkins is probably just using maven. How could Jenkins have a way of bypassing the setup in the pom? – Daniel Kaplan Jan 13 '13 at 00:16
  • @DanielKaplan hmm seems like the jenkins plugin uses it's own way because it releases it after the build completed. in the conole it only lists all the modules,prepares the artifacts and uploads them. So maybe there is no way :/. So the solution maybe would be to do it with the deploy maven plugin. There are also no settings for the plugin :/ – maxammann Jan 13 '13 at 01:51
  • @asgoth Please add that this does not work with the jenkins maven plugin, so I can add it as accepted answer – maxammann Jan 14 '13 at 12:41
  • Why you don't use the maven-release-plugin to perform the release? This plugin will execute goal deploy on your poms (which will be skipped for the poms with the above config) – asgoth Jan 14 '13 at 12:48
  • added info about maven-release-plugin – asgoth Jan 14 '13 at 12:51
  • @asgoth wouldn't it be also possible just to add the deploy plugin and a url? Dont exactly know what the release plugin does: https://community.jboss.org/wiki/MavenDeployingARelease?_sscc=t – maxammann Jan 14 '13 at 14:12
  • @asgoth oh "mvn deploy" and "mvn release:perform" are the same or? – maxammann Jan 14 '13 at 14:18
  • No... mvn release:prepare will prepare the release (will run mvn test and check if artifacts are ready to be released). mvn release:perform will run mvn deploy and make a tag in your source repository. It is best that your read here about [release:prepare](http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html) and [release:prepare](http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html) – asgoth Jan 14 '13 at 14:38
  • 4
    That didn't work for me - I have release plugin defined in root module and deploy plugin with skip configuration in submodule. And this submodule get deployed when i run `mvn release:perform` :'( – Askar Kalykov Aug 03 '16 at 10:31
  • @AskarKalykov any idea how to solve this? How to use the maven release plugin but skip certain modules? – Gerros Sep 28 '18 at 09:42
3

You could add a maven command line option to specify modules to be built in jenkins.

-pl,--projects <arg>                   Comma-delimited list of specified
                                       reactor projects to build instead
                                       of all projects. A project can be
                                       specified by [groupId]:artifactId
                                       or by its relative path.
Xiujun Ma
  • 2,574
  • 1
  • 14
  • 19
0

Aggregator projects' purpose is to combine building requirements for simple projects. If your basic projects have different building requirements, consider adding a new aggregator project.

Disable deployment to your Maven repository in your current aggregator project and create a new aggregator project containing only the modules you wish to deploy.

Add this new project to Jenkins, make it depend on your original project and configure it to be deployed to your repository.

Nicola Musatti
  • 17,834
  • 2
  • 46
  • 55
  • Your terminology appears to be off, what you appear to be describing is Parent projects. Parent projects are used for config, Aggregator projects define groups of projects to build. Sometimes the parent and aggregator are the same project. – Greg Domjan Jan 16 '14 at 17:23
  • 2
    building requirements = need to build, not configuration requirements/commonalities. Unfortunately some literature fails to distinguish between aggregation and parenthood, which serve different purposes and are best kept separate. This leads to people thinking that their projects can be included in at most one aggregator. This appears to be the case with the OP. – Nicola Musatti Jan 16 '14 at 17:39