For example:
maven-release-plugin prepare perform requires not having SNAPSHOT dependencies, this breaks the continuous integration in case of not being validated before the release, instead, flatten-maven-plugin only require -Drevision -Dchangelist scm:tag for tag the release version and not validate SNAPSHOT dependencies.
Having SNAPSHOT dependencies in a release version is always a bad idea. The build becomes non-reproducible.
The Maven Release Plugin offers you a thorough and thought-through release process. There are different opinions about some aspects of it, and if you don't like them, you can construct your own way, possibly in your build server (Jenkins) instead of Maven.
Related
What exactly is maven release plugin? What is its purpose? I found it in the middle of a tutorial but don't understand what it is useful for. Also, the teacher is showing us how to create tags on GitHub. What do the maven release plugin and GitHub have in common?
Fundamentally, "releasing a project" means that you have a version of your project that is stable and that you wish to release to the public ("publishing" could be a good synonym).
The maven release plugin helps you with several tasks that need to be done in order to release a project:
Make sure that the project uses no SNAPSHOT-dependencies (as SNAPSHOT-dependencies are considered unreleased and thus not necessarily stable)
Create a tag in your source control management system (in your case GitHub) so that you can come back to the released version e. g. if you need to fix a bug in an older release
Remove the -SNAPSHOT suffix from the project version in your pom.xml
Build the project
Deploy the project to your release repository (usually Maven Central).
Bump the version string in your pom.xml and add -SNAPSHOT again
Note that you can do all of these steps manually (e. g. you can simply edit your pom.xml and remove the -SNAPSHOT suffix and then run mvn deploy to deploy the project to Maven Central), but the release plugin helps with that as it automates those tasks and makes sure that you don't forget anything.
To answer what GitHub has to do with it: Again, the release plugin automatically creates a tag in your SCM so-that you can check it out some time later if you need to. It does not matter what your SCM is, it can be GitHub, Bitbucket, GitLab or whatever else. It's just that most people use GitHub as their SCM host.
Is it best practise to store snapshot versions in Artifactory in maven applications?
As snapshot versions should be used only for development purposes.
It's not true that SNAPSHOT versions should be used only for development. When SNAPSHOT version is uploaded it's not uploaded as is - it gets transformed into a unique version, something like this: 1-20150904.140213-59. When referencing such dependency you can:
either use SNAPSHOT word like 1-SNAPSHOT, then you don't really know which exact version is used
or use a resolved version: 1-20150904.140213-59
Using the 1st option is discouraged for any purpose - be it a deployment, or a <dependency> in pom.xml (even for development purposes), because it leads to non-repeatable actions. You run build once - you get a dependency with version 1-20150904.140213-59 downloaded, you run it for the 2nd time you may get another version like 1-20150904.140214-60.
But there's nothing wrong with referencing the full (resolved) version. So you can leverage snapshots the same way you do with release versions. Note though that remote repositories (e.g. Nexus) can be configured to delete old snapshot versions - so you need to take this into consideration.
By the way, snapshots are very convenient for releases.
A SNAPSHOT version is meant to be used for development. You can store it in Artifactory, but for using an artifact productively, you should build a release version.
#Stanislav is right that timestamped SNAPSHOTs could technically be used like release versions, and I believe him that this works, but I wouldn't do it because it is not how SNAPSHOTs and releases were meant to be.
In my team we develop several applications, all use the same in-house framework. This framework is separated to many sub modules, each with its own version, and each is published as a jar to artifactory (maven repository).
When we release an application we create a branch for it and we want to compile that branch against the latest release of each framework module (that's ok because in our nightly regressions we compile against the latest snapshot). We use gradle so this is done by setting the dependency version as "latest.release". This works great until we need to fix a bugs in production - then we release a patch for the released application by checking out the release branch, fixing the bug, compiling, validating and packaging the app.
Problem: latest.release now points to a different release version than the one we originally compiled against.
What I want: when releasing the app, burn all its resolved versions (the resolved latest.release) on the build.gradle (or in some other file) so when I compile it again in the future I will compile against the old releases.
I assume many developers face this issue, yet I haven't found any solution for this online. I never used maven but while searching for a solution I discovered there's a plugin in maven, release plugin, that does exactly what I need.
Would like to know if you have a solution for this problem.
Netflix has a plugin that handles locking dependency versions at releast time: https://github.com/nebula-plugins/gradle-dependency-lock-plugin
Alternatively, you can use this plugin: https://github.com/ben-manes/gradle-versions-plugin to identify dependencies that have newer versions, and replace them manually as needed.
Can any one let me know if there is any release plugin provided by gradle to do similar tasks performed as Maven release plugin do? I know we can load the maven tasks in gradle but do not want to do it and keep things clean if there is any inbuilt plugin provided by gradle. If there is one please please post sample config or code. Thanks in advance.
In maven we have the following tasks performed by maven release plugin:
release:clean Clean up after a release preparation.
release:prepare Prepare for a release in SCM.
release:prepare-with-pom Prepare for a release in SCM, and generate release POMs that record the fully resolved projects used.
release:rollback Rollback a previous release.
release:perform Perform a release from SCM.
release:stage Perform a release from SCM into a staging folder/repository.
release:branch Create a branch of the current project with all versions updated.
release:update-versions Update the versions in the POM(s).
Thanks
Nithin
Right there are so many choices. I tested most of the release plugins and wrote couple of them for different clients on my own. I really recommend the nebula-release plugin (https://plugins.gradle.org/plugin/nebula.nebula-release). This is driven by the netflix guys, well documented, well maintained and supports all kind of use cases and customizations.
For what its worth, I have recently published a gradle-release-plugin of my own (https://github.com/anshulverma/gradle-release-plugin).
It works on convention rather than configuration. Which is why I built it in the first place. Most of the time we all want the same thing -- semantic versioning with ability to snapshot and tag commits along with publish ability to OSS and bintray repositories. This is what this plugin provides and takes care of most of the configuration.
It is in active development at the moment. Feel free to open issues if any advancements come to mind.
I have been using mentioned townsfolk's release plugin, but it is not actively developed anymore with a few open issues (update: It seems that Daniel Tschinder took over development of that plugin, so probably there will be newer versions).
Recently I have found Axion release plugin which doesn't use separate file to keep current version, but uses Git commits and tags to determine it. It simplifies releasing process and fits in Continuous Delivery trend. What is also very important the author is very responsible.
In addition to the README file nice description can be found on their blog.
Axion itself do only versioning tests from your list, but it can be used together with maven-publish, bintray or any other publishing plugin to push artifacts into remote artifacts repository.
As far as I can tell, there are 4 release plugins right now.
https://github.com/townsfolk/gradle-release
https://github.com/ari/gradle-release-plugin
https://github.com/stianh/gradle-release-plugin
https://github.com/anshulverma/gradle-release-plugin
The townsfolk plugin is the one that works the most like the maven plugin and it works quite well so far ... but is currently not maintained (see github). The other 2 plugins work much differently from the maven release plugin (and pretty similarly to each other). These other two plugins use version control (svn/git) to keep track of version numbers instead of burying (and updating) version numbers in the build.gradle file.
You can also find various approaches here: https://bitbucket.org/evgenyg/demo-releases-plugin/src/master/build.gradle
And some nice slides here: http://www.slideshare.net/evgenyg/release-it
Hope this helps!
I know, its not a good practice to release a project with SNAPSHOT dependencies.
But, I would like to know, Is there any way, we can make maven release plugin to release with SNAPSHOT dependencies?
Is there any parameters that I can pass to the maven release plugin to accept SNAPSHOT version of the dependencies while releasing?
Like
-Dallow.snapshots= true
You could consider using the allowTimestampedSnapshots option to release:prepare. This was apparently added to deal with use-cases where SNAPSHOT dependencies are unavoidable.
But you should only do this if it is unavoidable. Among other things, some Maven repositories can be configured to automatically delete old SNAPSHOT releases. If that happened, your released artifacts could end up with permanently broken dependencies.
Why would you want that? A released version is supposed to never change. Updating one of the snapshot dependencies risks breaking the system. I see two approaches:
Either you have control over the source code of your dependencies, in which case I recommend you to go through the, albeit tedious, process of releasing those projects.
If you don't control the source code you can still rename the binary and manually upload it to your release server. You might still take this approach even for projects under your control, although I strongly encourage you not to.