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!
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.
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.
I have a library and a program, both under my control and built using Gradle. What's the best way to develop these two at the same time?
I have set up a private maven repository to distribute the library and that's working, but I don't want to release to that repository every little experiment I make during development. It's slow and disruptive to users of the library.
I tried installing the jar to the local maven repository as explained here: Gradle alternate to mvn install but the project that's using the library is not picking up that newly installed version.
I think, you can try to use multi-project builds for that if it's possible. But you will likely need to restructure both your current projects to become modules of the same new project.
What's the best way to develop these two at the same time?
It depends by how the team is organized and what are your policies.
Of course if the team can use a git repo and access to the source code you can just use git without pushing a new version on the maven server for each commit or push.
Otherwise if other users can only use the final library, you have to push the version on the maven server.
I have set up a private repository to distribute the library and that's working, but I don't want to release to that repository every little experiment I make during development. It's slow and disruptive to users of the library.
Every maven repo has 2 different repositories:
release
snapshot
Usually release repo is used only for stable releases and the snapshot repo is used to publish little change, beta release and so on.
In any case it is not required that every changes in the code is pushed in the maven repo (it is a your choice)
It's slow
The time to upload artifacts usually is not so big, in any case you can evaluate to push the release in the maven repo with a CI server.
The best method seems to be to make one project include the other one when present by adding:
if (file("../libraryproject").exists()) {
includeBuild "../libraryproject"
}
to the settings.gradle file of the project that uses the library. That can be committed to the source code repo because when that directory doesn't exist, the dependency will be included in the traditional way.
This is called Composite Build in the Gradle world, IntelliJ seems to handle properly and theres'a recorded webcast showing the whole setup: https://www.youtube.com/watch?v=grPJanXfRPg
I have a Maven project that needs to be versioned. I have chosen to use the versions-maven-plugin as my versioning plugin but am unsure if that's the best option.
I have read the documentation that such plugin actually modifies the POM and I don't really like that approach. I have worked on projects where they had separate build.properties file that got modified manually.
What I want to achieve is to have my CI generating the artifact for me ready to be deployed and update the version number automatically.
So, any suggestions? How have you done before?
Thank you
I'd get the version number from the one source that matters: that's the source code management system (Subverson, Mercurial, or Git), not Maven.
I'd say that Maven might be out of synch unless your Maven plug-in is getting it from SCM.
Use the Release Plugin. You want to perform automatic deployment and batch release. The Versions Plugin is designed for something else.
We have found MAVEN-RELEASE-PLUGIN super useful and can not imagine releasing and managing version with it.
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.