4

Setup

I have a project with a child project and want to do a maven release of the child (Project B):

Project-A/
  pom.xml
  Project-B/
    pom.xml
    src/

The folder of Project-A is at the same time my git repository, which I clone from our central git server.

For our release we use the jenkins as build server with the Jenkins Maven Release Plug-in to start the release build.

So after the jenkins Job (called JobB) is started it will checkout the Project-A folder into the following place: /Users/titan/.jenkins/jobs/JobB/workspace.

Due to the way how git is working I can only clone the top level of my structure. So this means I need to set the pom I want to build in jenkins to Project-B/pom.xml which then will change the working directory maven uses for doing its work.

This creates a lot of issues with git as the maven release plugin tries to commit to the wrong directory (it assumes that Project-A/Project-B/ is a valid git repository). I could solve all such issues (by deactivating the pushes to the remote repo when doing the release and specifying the correct scm url when doing the release.)

This is the value of the Release goals and options field in the jenkins JobB configuration:

-X -DpreparationGoals="clean install" 
-DpushChanges=false 
-DconnectionUrl=scm:git:file:///Users/titan/.jenkins/jobs/JobB/workspace 
release:prepare release:perform

The file url for the connectionUrl is needed because I do not push the changes to the git remote server and the clone which is done at the beginning of maven:perform would not find the tag from which it needs to checkout.

Issue

And after all this here is my issue which I'm not able to solve:

The maven:prepare step runs through and does all its work (changing version numbers in pom, creating release tag). Then the maven:perform step starts, clones the content from the git repository, checkouts tag into the target folder, and then invokes the deploy command.

But here is the issue the invoked deploy command is invoked on the top level so it is deploying Project-A instead of the Project-B. The job itself is running through without any errors it is just building and deploying the wrong thing.

Here is the command maven generates to execute the deploy:

[INFO] Executing goals 'deploy'...
[DEBUG] Using ${maven.home} of: '/usr/share/java/maven-3.0.3'.
[DEBUG] Executing: /bin/sh -c cd /Users/titan/.jenkins/jobs/jobB/workspace/Project-B/target/checkout && /usr/share/java/maven-3.0.3/bin/mvn -B -X -D maven.repo.local=/Users/titan/.m2/repository -s /Users/titan/.m2/settings.xml -D performRelease=true deploy

So it is invoking the pom file inside the checkout directory instead inside checkout/Project-B. Interestingly the maven:prepare step does execute on the correct pom.

What I tried so far

  • Not using jenkins, and invoking the mvm command directly from the shell. This gives me the same outcome. So I assume that jenkins is not the issue.

  • Changing the path for the pom with the -Darguments="-f sword-packaging-wbf/pom.xml" and with -Darguments="-DpomFileName=sword-packaging-wbf/pom.xml"

    Both methods do not change anything in the outcome. And looking at the output I see that the -f <path> is ignored in the generated commands where as the -DpomFileName is visible but does not change anything in the outcome.

Community
  • 1
  • 1
Chris
  • 728
  • 7
  • 28
  • 1
    It sounds like your origanzation of your project wrong, cause if you try to release a sub-module it should be a separate project. If your Project-A has no real meaning or as you wrote you don't release it so it does make sense to have a parent pom in your project-A. What i don't understand why you don't like to release your Project-A instead of Project-B – khmarbaise Apr 26 '12 at 17:29
  • I think I got the names wrong, I should not be talking about a sub-module in this case. As the Projekt-B is actually just a child of project-A. Project A is just a pom which contains some plugin settings which are needed in Project-A (And I have not only a Project-B but also a Project-C and D, the Project-A just contains the common rules for building). – Chris Apr 27 '12 at 05:05
  • 2
    Exactly what i thought you have. Do you have a parent tag in your child modules? If yes you have a multi-module build. In this case you have to do the release of parent (which implies childs will be released as well) and not a child module alone. Furthermore if all childs and the parent of a multi-module build have been released every childs can be used a dependency alone if you need. – khmarbaise Apr 27 '12 at 06:04
  • Yes I have a parent tag in my childs. But I have no module tags in the parent. So a build of the parent project will not build any of the childs. And for me it would also not make any sense to put the module tags into the parent as the child modules are each builded on different times and do not share the same version. – Chris Apr 27 '12 at 06:13
  • So this means your organization is simply wrong. Put your parent into a separate maven module (also separate git repos) release it. In your child modules just use the parent and make your childs separate maven modules as well as git repos and release them separately. That's it. Otherwise you start fighting with Maven and you will loose the combat. – khmarbaise Apr 27 '12 at 07:11
  • So it would go into the direction of the following answer: http://stackoverflow.com/a/2002304/117959. Could you make your comment an answer? Because you were right and it is a possible solution to my problem. And I just learned something about maven structure again. – Chris Apr 27 '12 at 07:41

1 Answers1

8

So this means your organization is simply wrong. Put your parent into a separate maven module (also separate git repos) release it. In your child modules just use the parent and make your childs separate maven modules as well as git repos and release them separately. That's it. Otherwise you start fighting with Maven and you will loose the combat.

khmarbaise
  • 92,914
  • 28
  • 189
  • 235
  • Just this answer is complete for me: When using the version 2.2.2 of the maven release plugin then the release works when started from a top level folder (using the -f argument). – Chris May 07 '12 at 09:04
  • 1
    like the final comment... "you will loose the combat" the trick for me was: the root of repository must have the pom... if you star a module (folder in the top of repository) the conver to multi-module :) – accreativos Dec 09 '13 at 15:21
  • 2
    +1 just for saying "If you start fighting with Maven, you will lose the combat". Sad, but so true. – LordOfThePigs Apr 03 '14 at 10:42