mvn release does not work, only publishes SNAPSHOT releases

Georg Gruetter

unread,

Feb 28, 2013, 7:36:11 PM2/28/13

to jenkin...@googlegroups.com

Hi all,

this is a followup of a thread I started earlier. I'm trying to publish my first release of the stashnotifier plugin but continue to fail. Here's what happens

I am ready to perform a maven release (SNAPSHOT version, all changes committed and pushed to GitHub). I'm on the develop branch (I usually use the git-flow branching model and tried the same on a release branch - same problem. I haven't tried this on the master branch though).
I perform mvn release:prepare release:perform
When prompted for the release version, I enter 1.0.2 (current + next SNAPSHOT version is 1.1-SNAPSHOT)
the release runs through successfully without any error but only publishes the SNAPSHOT version

I think the problem occurs in the release:prepare. After release:prepare, I'd expect so see a commit in my local repository where the artifact version in my pom.xml is set to the release version (1.0.2). However - no commit. As a result, the artifact version is still 1.1-SNAPSHOT and I guess that's why maven decides to deploy it to the SNAPSHOTS repository. Tagging works and the tag is also pushed to the remote.

From what I can tell, maven sort of omits the commit command and no changes are pushed as a result:

[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git add -- pom.xml
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git status
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Tagging release with the label stashNotifier-1.0.2...
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git tag -F /var/folders/dr/xxbtyycs1z9dl2_snlj87zrh0000gn/T/maven-scm-678409272.commit stashNotifier-1.0.2
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git push g...@github.com:jenkinsci/stashnotifier-plugin.git stashNotifier-1.0.2
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git ls-files
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Transforming 'Stash Notifier'...
[INFO] Not removing release POMs
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git add -- pom.xml
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git status
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Release preparation complete.

I have appended the complete mvn output of the release run for your reference. I'm running Maven 3.0.3, by the way. Can anyone please tell me what I'm doing wrong? I'm banging my head against the wall on this for a couple of days now.

Thanks for your help and cheers,
Georg

release-log.txt

Baptiste MATHUS

unread,

Mar 2, 2013, 4:44:14 PM3/2/13

to jenkin...@googlegroups.com

Hi, might not be helpful at all, but here's my 2 cents:
* upgrade to mvn 3.0.4 or 3.0.5, 3.0.3 have had some issues that even led jenkins core to forbid building with it
* which mvn-release-p version are you using? 2.4 has some issues with git. Prefer sticking to 2.3.2 before it's fixed.

Hth,
Cheers

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Georg Gruetter

unread,

Mar 3, 2013, 9:02:27 AM3/3/13

to jenkin...@googlegroups.com, m...@batmat.net

Hi Baptiste,

* upgrade to mvn 3.0.4 or 3.0.5, 3.0.3 have had some issues that even led jenkins core to forbid building with it

I already upgraded to 3.0.5 but the problem persists.

* which mvn-release-p version are you using? 2.4 has some issues with git. Prefer sticking to 2.3.2 before it's fixed.

I'm using 2.2.2 as prescribed by the jenkins parent pom version 1.498. I'll try manually setting 2.3.2 when I do the next release. Thanks for the tip.

Cheers,
Georg

Bernhard Friedreich

unread,

Mar 25, 2013, 5:04:23 AM3/25/13

to jenkin...@googlegroups.com, m...@batmat.net

I'm having the same problem using maven directly for releasing to the git repository (mvn release:prepare release:perform).

Using maven-release-plugin 2.4 it builds the snapshot version as release - using version 2.3.2 it works as intended :)

Is there already a bugreport somewhere?

Regards,
Bernhard Friedreich

ogondza

unread,

Jan 4, 2014, 11:17:19 AM1/4/14

to jenkin...@googlegroups.com

I have seen this problem today using:

maven 3.1.1

maven-releas-plugin 2.2.2

git 1.8.5

Worked around downgrading git to 1.8.4.

http://jira.codehaus.org/browse/MRELEASE-812

--

oliver

Nigel Magnay

unread,

Jan 12, 2014, 5:52:40 AM1/12/14

to jenkin...@googlegroups.com

I've just had this problem too, with two separate plugins.

maven-release-plugin is just total crapola. Just do a manual mvn versions:set and deploy.

Dominik Bartholdi

unread,

Jan 12, 2014, 5:55:26 AM1/12/14

to Jenkins Developers

The maven team has just release a git provider based on jgit, if you configure the release plugin to use this one, then you don’t have to downgrade git.

http://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/index.html

/Domi

Stephen Connolly

unread,

Jan 13, 2014, 3:21:17 AM1/13/14

to jenkin...@googlegroups.com

On Sunday, 12 January 2014, Dominik Bartholdi wrote:

The maven team

Nice dodge of self promotion there

;-)

Btw do you want to take a run at m-r-p?

Sent from my phone

Dominik Bartholdi

unread,

Jan 13, 2014, 1:03:11 PM1/13/14

to Jenkins Developers

;-)

I’ll try to take a look at the m-r-p, but I currently can’t promise any time - sorry :(

/Domi

Vincent Latombe

unread,

Jan 14, 2014, 11:47:35 AM1/14/14

to Jenkins Dev

I hit that problem recently, adding

<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>${maven-release-plugin.version}</version>
<dependencies>
    <dependency>
      <groupId>org.apache.maven.scm</groupId>
      <artifactId>maven-scm-provider-gitexe</artifactId>
      <version>1.9</version>
    </dependency>
</dependencies>
</plugin>

was enough to work with latest git (1.8.5.2).

HTH,

Vincent

2014/1/13 Dominik Bartholdi <do...@fortysix.ch>

Stefan Wolf

unread,

Feb 10, 2014, 5:16:31 PM2/10/14

to jenkin...@googlegroups.com

Should we pull a new release of https://github.com/jenkinsci/pom incoporating the changes to the release plugin configuration?

Vincent

2014/1/13 Dominik Bartholdi <do...@fortysix.ch>

;-)

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ulli Hafner

unread,

Feb 11, 2014, 12:52:07 PM2/11/14

to jenkin...@googlegroups.com

That would be helpful, yes.

BTW: This fix does only work if the project is not in a sub-folder :-(

Ulli

signature.asc

Ulli Hafner

unread,

Mar 8, 2014, 6:25:20 AM3/8/14

to jenkin...@googlegroups.com

Has someone a workaround for that problem if the plugin/libray to release is not in the top-level folder of a git project?

My findbugs plugin is divided into

- findbugs-plugin/library shaded findbugs library

- findbugs-plugin/plugin actual findbugs plugin

When I try to release maven does only publish a SNAPSHOT.

signature.asc

Stephen Connolly

unread,

Mar 8, 2014, 6:36:30 AM3/8/14

to jenkin...@googlegroups.com

What version of git are you using?

Anything after 1.8.4 needs m-r-p 2.5 or the dependency hack

Ulli Hafner

unread,

Mar 8, 2014, 11:05:54 AM3/8/14

to jenkin...@googlegroups.com

git version is 1.8.5.3

The dependency hack does only work if the plugin is top-level. I’m releasing in a sub-folder.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

signature.asc

Stephen Connolly

unread,

Mar 8, 2014, 2:05:15 PM3/8/14

to jenkin...@googlegroups.com

mvn org.apache.maven.plugins:maven-release-plugin:2.5:prepare

And if that tags correctly then same with perform. Should fix the -SNAPSHOT issue... The other issue could be a different story

Ivan Kalinin

unread,

May 13, 2014, 6:46:39 PM5/13/14

to jenkin...@googlegroups.com

Has similar problem recently and your fix did help. But latest parent (http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-ci/jenkins/1.33/) still uses 2.2.2 -- is there any plan to fix that?

On Saturday, March 8, 2014 11:05:15 PM UTC+4, Stephen Connolly wrote:

mvn org.apache.maven.plugins:maven-release-plugin:2.5:prepare

And if that tags correctly then same with perform. Should fix the -SNAPSHOT issue... The other issue could be a different story

On Saturday, 8 March 2014, Ulli Hafner <ullrich...@gmail.com> wrote:

git version is 1.8.5.3

The dependency hack does only work if the plugin is top-level. I’m releasing in a sub-folder.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Stephen Connolly

unread,

May 14, 2014, 5:26:24 AM5/14/14

to jenkin...@googlegroups.com

Well I have long maintained that Jenkins's pom structure "does it all wrong" but any time I have wanted to try and fix it *and* had a time window to try, KK puts too much of a barrier with regard to people getting confused.

I guess it doesn't help that to fix it, I need to redo the hpi plugin so that it actually works the Maven way... but then if the people who wrote the original hpi plugin understood the Maven way they would never have written the Maven project type in Jenkins the way they did and it would not be evil!

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Ivan Kalinin

unread,

May 15, 2014, 4:45:23 AM5/15/14

to jenkin...@googlegroups.com

Have u got any patches / pull requests one can look at?

Stephen Connolly

unread,

May 15, 2014, 6:30:05 AM5/15/14

to jenkin...@googlegroups.com

Ha! When I do get around to fixing this it will look a lot like NIH syndrome, because quite frankly most of the current parent pom is overbaked and too heavyweight and includes too many workarounds for the incorrect design within the hpi plugin.

Pull requests would not be compatible with the scope of change required to do this right

Ivan Kalinin

unread,

May 16, 2014, 4:04:46 AM5/16/14

to jenkin...@googlegroups.com

Hehehe. So there is no hope for fixing this ever?
At least, could you be so kind as to describe those neccessary changes that should fix the project layout? Like removing the extra depends/versions? Or separating the Jenkins pom from plugin pom?

Stephen Connolly

unread,

May 16, 2014, 5:47:20 AM5/16/14

to jenkin...@googlegroups.com

You can put band-aids... for example we use internally a parent pom that decouples from core, something very close to

<?xml version="1.0" encoding="UTF-8"?>

<groupId>com.cloudbees</groupId>

<artifactId>cloudbees-internal-parent</artifactId>

</parent>

<groupId>com.cloudbees.jenkins.plugins</groupId>

<artifactId>jenkins-plugins</artifactId>

<version>23-SNAPSHOT</version>

<name>CloudBees Jenkins Plugin Parent</name>

<description>The CloudBees Jenkins Plugins Parent Project</description>

<scm>

</scm>

<jenkins.version>1.532.2</jenkins.version>

<hpi-plugin.version>1.108</hpi-plugin.version>

<stapler-plugin.version>1.17</stapler-plugin.version>

<java.level>6</java.level>

<concurrency>1</concurrency>

</properties>

</prerequisites>

<artifactId>jcip-annotations</artifactId>

</dependency>

<groupId>com.github.stephenc.findbugs</groupId>

<artifactId>findbugs-annotations</artifactId>

</dependency>

<groupId>com.google.code.findbugs</groupId>

</dependency>

<groupId>org.jenkins-ci.main</groupId>

<artifactId>jenkins-core</artifactId>

<version>${jenkins.version}</version>

</dependency>

<groupId>org.jenkins-ci.main</groupId>

<artifactId>jenkins-war</artifactId>

<version>${jenkins.version}</version>

</dependency>

<groupId>org.jenkins-ci.main</groupId>

<artifactId>jenkins-test-harness</artifactId>

<version>${jenkins.version}</version>

</dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

<groupId>javax.servlet</groupId>

<artifactId>servlet-api</artifactId>

</dependency>

</dependencies>

</dependencyManagement>

<artifactId>jcip-annotations</artifactId>

<scope>provided</scope>

</dependency>

<groupId>com.github.stephenc.findbugs</groupId>

<artifactId>findbugs-annotations</artifactId>

<scope>provided</scope>

</dependency>

<groupId>com.google.code.findbugs</groupId>

<scope>provided</scope>

</dependency>

<groupId>javax.servlet</groupId>

<artifactId>servlet-api</artifactId>

<scope>provided</scope>

</dependency>

<groupId>org.jenkins-ci.main</groupId>

<artifactId>jenkins-core</artifactId>

<scope>provided</scope>

</dependency>

<groupId>org.jenkins-ci.main</groupId>

<artifactId>jenkins-war</artifactId>

</dependency>

<groupId>org.jenkins-ci.main</groupId>

<artifactId>jenkins-test-harness</artifactId>

<groupId>junit</groupId>

<artifactId>junit-dep</artifactId>

</exclusion>

</exclusions>

</dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

</dependencies>

<build>

<!--

Since new versions need to overwrite old versions, it's better

not to have version number in the .hpi file name.

-->

<finalName>${project.artifactId}</finalName>

<artifactId>maven-compiler-plugin</artifactId>

</plugin>

<artifactId>maven-dependency-plugin</artifactId>

</plugin>

<artifactId>maven-eclipse-plugin</artifactId>

<!--

Because Eclipse lacks JSR-269 support, put the output

to a different directory

-->

<buildOutputDirectory>target/eclipse-classes</buildOutputDirectory>

<projectnature>org.eclipse.jdt.groovy.core.groovyNature</projectnature>

</additionalProjectnatures>

</configuration>

</plugin>

<artifactId>maven-failsafe-plugin</artifactId>

</plugin>

<artifactId>maven-jar-plugin</artifactId>

</plugin>

<artifactId>maven-resources-plugin</artifactId>

</plugin>

<artifactId>maven-surefire-plugin</artifactId>

</plugin>

<artifactId>maven-war-plugin</artifactId>

</plugin>

<groupId>org.codehaus.gmaven</groupId>

<artifactId>gmaven-plugin</artifactId>

</plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>apt-maven-plugin</artifactId>

<version>1.0-alpha-5</version>

</plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>build-helper-maven-plugin</artifactId>

</plugin>

<groupId>org.jacoco</groupId>

<artifactId>jacoco-maven-plugin</artifactId>

</plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>findbugs-maven-plugin</artifactId>

</plugin>

<groupId>org.kohsuke.gmaven</groupId>

<artifactId>gmaven-plugin</artifactId>

<version>1.0-rc-5-patch-2</version>

</plugin>

<groupId>org.kohsuke.stapler</groupId>

<artifactId>maven-stapler-plugin</artifactId>

<version>${stapler-plugin.version}</version>

</plugin>

<groupId>org.jenkins-ci.tools</groupId>

<artifactId>maven-hpi-plugin</artifactId>

<version>${hpi-plugin.version}</version>

</plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>animal-sniffer-maven-plugin</artifactId>

</plugin>

<groupId>org.jvnet.localizer</groupId>

<artifactId>maven-localizer-plugin</artifactId>

</plugin>

<groupId>org.jvnet.maven-antrun-extended-plugin</groupId>

<artifactId>maven-antrun-extended-plugin</artifactId>

</plugin>

<groupId>org.jvnet.sorcerer</groupId>

<artifactId>maven-sorcerer-plugin</artifactId>

</plugin>

<groupId>org.kohsuke</groupId>

<artifactId>access-modifier-checker</artifactId>

</plugin>

<groupId>org.mortbay.jetty</groupId>

<artifactId>maven-jetty-plugin</artifactId>

</plugin>

<groupId>com.cloudbees</groupId>

<artifactId>maven-license-plugin</artifactId>

</plugin>

</plugins>

</pluginManagement>

<artifactId>maven-enforcer-plugin</artifactId>

<id>display-info</id>

<phase>validate</phase>

<goals>

<goal>display-info</goal>

<goal>enforce</goal>

</goals>

<rules>

<maxJdkVersion>1.${java.level}</maxJdkVersion>

<exclude>org.jenkins-ci.main:jenkins-core</exclude>

<exclude>org.jenkins-ci.main:cli</exclude>

<exclude>org.jenkins-ci.main:jenkins-test-harness</exclude>

</excludes>

<!-- To add exclusions in a Jenkins plugin, use:

<artifactId>maven-enforcer-plugin</artifactId>

<id>display-info</id>

<rules>

</excludes>

</enforceBytecodeVersion>

</rules>

</configuration>

</execution>

</executions>

</plugin>

(or just override java.level) -->

</enforceBytecodeVersion>

</rules>

</configuration>

</execution>

</executions>

<groupId>org.codehaus.mojo</groupId>

<artifactId>extra-enforcer-rules</artifactId>

</dependency>

</dependencies>

</plugin>

<artifactId>maven-compiler-plugin</artifactId>

<source>1.${java.level}</source>

<target>1.${java.level}</target>

</configuration>

</plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>animal-sniffer-maven-plugin</artifactId>

<goals>

<goal>check</goal>

</goals>

<id>check</id>

</execution>

</executions>

<groupId>org.codehaus.mojo.signature</groupId>

<artifactId>java1${java.level}</artifactId>

</signature>

</configuration>

</plugin>

<artifactId>maven-eclipse-plugin</artifactId>

</plugin>

<groupId>org.jenkins-ci.tools</groupId>

<artifactId>maven-hpi-plugin</artifactId>

<contextPath>/jenkins</contextPath>

</configuration>

</plugin>

<groupId>org.kohsuke.stapler</groupId>

<artifactId>maven-stapler-plugin</artifactId>

</plugin>

<artifactId>maven-release-plugin</artifactId>

<goals>deploy</goals>

</configuration>

</plugin>

<groupId>org.jvnet.localizer</groupId>

<artifactId>maven-localizer-plugin</artifactId>

<goals>

<goal>generate</goal>

</goals>

<fileMask>Messages.properties</fileMask>

<outputDirectory>target/generated-sources/localizer</outputDirectory>

</configuration>

</execution>

</executions>

</plugin>

<artifactId>maven-javadoc-plugin</artifactId>

</plugin>

<groupId>org.kohsuke</groupId>

<artifactId>access-modifier-checker</artifactId>

</plugin>

<groupId>org.codehaus.gmaven</groupId>

<artifactId>gmaven-plugin</artifactId>

<id>test-in-groovy</id>

<goals>

<goal>generateTestStubs</goal>

<goal>testCompile</goal>

</goals>

</execution>

</executions>

</dependency>

</dependencies>

</plugin>

<artifactId>maven-surefire-plugin</artifactId>

<name>hudson.udp</name>

</property>

</systemProperties>

<forkCount>${concurrency}</forkCount>

</configuration>

</plugin>

<groupId>com.cloudbees</groupId>

<artifactId>maven-license-plugin</artifactId>

<goals>

<goal>process</goal>

</goals>

<phase>prepare-package</phase>

<generateLicenseXml>target/${project.artifactId}/WEB-INF/licenses.xml</generateLicenseXml>

<inlineScript><![CDATA[

filter {

def plugins = [] as Set

// collect all Jenkins plugins

models.entrySet().each { e ->

if (e.value.packaging=="hpi")

plugins.add(e.key.id)

}

// filter out dependencies that don't belong to this plugin

models.entrySet().removeAll(models.entrySet().findAll { e ->

def a = e.key;

if (a.dependencyTrail.size()>0 && plugins.contains(a.dependencyTrail[1]))

return true; // ignore transitive dependencies through other plugins

// if the dependency goes through jenkins core, we don't need to bundle it in the war

// because jenkins-core comes in the <provided> scope, I think this is a bug in Maven that it puts such

// dependencies into the artifact list.

if (a.dependencyTrail.find { trail -> trail.contains(":hudson-core:") || trail.contains(":jenkins-core:") })

return true;

return false;

})

}

]]></inlineScript>

</configuration>

</execution>

</executions>

</plugin>

<groupId>org.jacoco</groupId>

<artifactId>jacoco-maven-plugin</artifactId>

<goals>

<goal>prepare-agent</goal>

</goals>

</execution>

<id>report</id>

<phase>prepare-package</phase>

<goals>

<goal>report</goal>

</goals>

</execution>

</executions>

<exclude>**/Messages.class</exclude>

</excludes>

</configuration>

</plugin>

</plugins>

</build>

<id>all-tests</id>

</property>

</activation>

<maven.test.redirectTestOutputToFile>true</maven.test.redirectTestOutputToFile>

</properties>

</profile>

</profiles>

</project>

That whole business of over-specifying plugin versions of *every plugin in the world* is a whole waste of time. Especially the over-reliance on properties to control the versions. There are only two reasons to use properties for versions:

1. You want to keep the same version in sync

2. You need to be able to override the version from the command line.

So in our case with the above pom, if you want to check your plugin against a different version of jenkins

$ mvn hpi:run -Djenkins.version=1.553

$ mvn hpi:run -Djenkins.version=1.561

Because of vagrancies of the hpi and stapler plugins, sometimes when you are testing with a newer version of Jenkins you also need to use a newer version of the hpi or stapler plugins, hence those have versions controlled by properties.

The only other plugins we configure are ones that we want as part of our standard build process.

Keep things only as light as they need to be... FYI https://github.com/jenkinsci/pom/blob/master/pom.xml#L614 is insane. If people need a newer version in their plugin's pom, they should just frickin do it the Maven way and add a pluginManagement entry... why are we teaching people the wrong ways of doing Maven? The only plugins that should have their versions specified are the ones that are in the lifecycle of expected child poms. If a child pom is adding a plugin it is up to that child pom to correctly specify the version if it is not inherited. We should not be providing versions of plugins "just in case" somebody decides to add the plugin to their pom.

Keep in mind that reving the parent pom is a *big deal*... the current parent makes that double big deal... at least internally reving the parent is ok other than we need to do a bit of work pushing the rev to all our plugin source repos so that we don't forget to update it again before the next plugin release

Now is the CloudBees style-parent something that the Jenkins community should adopt? Well there was an action item on myself and Jesse Glick to see about pushing something based on our parent into OSS as an alternative... perhaps... though my personal preference is not to force two parent switching churns on plugin developers.

As such I would rather fix the hpi plugin so that people can have a "Maven plugin done right" experience out of the box and see that the Maven pains of Jenkins plugin development are actually a result of not having the Maven build done right in the first place and not an intrinsic problem of Maven (other than our docs are non-existent and thus people don't learn the right way of writing maven plugins)

-Stephen

On 16 May 2014 09:04, Ivan Kalinin <pups...@gmail.com> wrote:

Hehehe. So there is no hope for fixing this ever?
At least, could you be so kind as to describe those neccessary changes that should fix the project layout? Like removing the extra depends/versions? Or separating the Jenkins pom from plugin pom?

Markus Pfeiffer

unread,

Jul 30, 2014, 9:59:55 AM7/30/14

to jenkin...@googlegroups.com

I've run into the same issue using git 1.9.1 + maven 3.2.2 on Ubuntu and git 1.8.5.2 + maven 3.1.1 on Mac. The release version is never committed and never appears in the store. I also seem to be in the same boat as Ulrich Hafner, our Jenkins plugin is in a subfolder of the git repository and none of the workarounds seem to work.

I've used nigelm's tip and simply did a manual deploy using a combination of mvn version:set and mvn deploy. To simplify the process in the future I've written a simple bash script that others may find useful:

#!/bin/bash
# --------------------------------------------------------------------------------
NAME=<<tag-name>>
echo Preparing $NAME for release

# Query user for info
read -p "Enter version number to use for the release: " VERSION_RELEASE
read -p "Enter name for the release tag [$NAME-$VERSION_RELEASE]: " TAG_RELEASE
read -p "Enter version number for next development iteration: " VERSION_SNAPSHOT

if [[ -z "$TAG_RELEASE" ]]; then
TAG_RELEASE=$NAME-$VERSION_RELEASE
fi

if [[ "$VERSION_SNAPSHOT" != *-SNAPSHOT ]]; then
VERSION_SNAPSHOT=$VERSION_SNAPSHOT-SNAPSHOT
fi

# Show info for review
echo
echo "Release version : $VERSION_RELEASE"
echo "Tag release with : $TAG_RELEASE"
echo "Next iteration : $VERSION_SNAPSHOT"
read -p "Continue (y/N)? " -s -n1 KEY
echo

if [[ "$KEY" != "y" ]]; then
echo "Aborted"
exit
fi

# Set the new version, commit, create a tag
mvn versions:set -DnewVersion=$VERSION_RELEASE
git add pom.xml
git commit -m "prepare release $TAG_RELEASE"
git tag $TAG_RELEASE

# Deploy the new version
mvn deploy

# Set the new snapshot version, commit
mvn versions:set -DnewVersion=$VERSION_SNAPSHOT
git add pom.xml
git commit -m "prepare for next development iteration"

# Push changes and tags
# git push
# git push --tags

# Clean up backup files
# rm pom.xml.versionsBackup

echo
echo "done."

The push is commented out just to be on the save side.

Stephen Connolly

unread,

Jul 30, 2014, 10:15:00 AM7/30/14

to jenkin...@googlegroups.com

there is a much simpler way to get a release:

instead of doing

$ mvn release:prepare release:perform

(with the -B if you are feeling YOLO)

you do

$ mvn org.apache.maven.plugins:maven-release-plugin:2.5:prepare org.apache.maven.plugins:maven-release-plugin:2.5:perform

Simples

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.