I think there are really good tutorials on how to use the Plugin SDK, how to create the plugin skeleton etc. There are also some good guildelines (well, currently already obsolete, but still nice) what is the process needed for applying a plugin for plugin exchange, but towards its end I miss a step-by-step guides especially about releasing of the plugin.

What I miss though (couln't find it) is a step by step instructions how to use atlas-release command. I also got some very confusing information about the contrib maven repository. I don't know now - is it mandatory to have an account there or not?

My plugin will be hosted on bitbucket and I would be very grateful for simple instructions: what to put in my pom.xml when I want to release my plugin? What should be the <scm> configuration for git on bitbucket, what should be my <repositories> in pom.xml.

Also, would be useful to explain shortly for example, how to use I guess atlas-mvn to build javadocs or sources.

Yes, I am a newbie in maven who knows Java in general and so far I was able to follow the available instructions, but now I am stuck with not knowing how to release the thing. I am afraid of running the maven release commands just to try things because I know it can cause some sideeffect to my local repo which are maybe hard to rollback (for a newbie).

1 answer

I can give you a part of the answer, but some people are more relevant about the Maven Release plugin and the way the Atlassian Contrib repo is managed. There is a page on DAC about the Atlassian Repositories and how to declare them in your pom.xml.

If you look at the source code of AMPS (ReleaseMojo), it is just calling mvn release:prepare and mvn release:perform, so I suggest you call these commands directly, and get information on the website of maven-release-plugin about the details. There is a guide to releasing on the plugin's website. Note that old versions had an issue with Git, so check you're using the very last one.

Imagine you're developing THING 1.0-SNAPSHOT. In git, your pom.xml reads "<version>1.0-SNAPSHOT</version>" while you develop, then you want to deliver 1.0. You will keep developing version 2, so the new version will be 2.0-SNAPSHOT.

"mvn release:prepare"

Will ask you 3 questions:

Which version do you want to release? 1.0

What should be the name of the tag? (This depends on your tag name policy, but there's no reason not to accept the default) thing-1.0

What should be the new development version? 2.0-SNAPSHOT

Will compile your project, execute the tests and commit 3 things:

A first commit where "1.0-SNAPSHOT" is replaced with "1.0", with the commit message "[maven-release-plugin] Prepare release thing-1.0";

A tag of the previous commit;

A second commit where "1.0" is replaced with "2.0-SNAPSHOT", with the commit message "[maven-release-plugin] Prepare next developent version" (or similar).

(It is not clear to me whether maven-release-plugin takes care of git pull/push before and after doing these commits).

Will write the file release.properties.

"mvn release:perform"

Will checkout the tag into the target/ directory;

Will compile this target directory and push the artifacts to the Contrib repo.

Will execute any additional task suggested by the plugins of your pom.xml: Compile the Javadoc, compile the source JARs, etc.

Will delete the file release.properties.

How to rollback:

If release:prepare fails, it probably didn't commit anything. Check nothing was committed, clean up your local directory (mvn release:clean for example) and start again. If something was committed, you can revert things manually (rm -rf * ; git reset --hard commit-id) or use mvn release:rollback if you trust Maven.

If release:perform fails, try doing it again after fixing the failure. Release:perform doesn't make commits, so you should be able to re-execute. Note that it requires the release.properties file; If you've deleted it, you still have the option of checking out the tag and running mvn release:perform from there.