Hello Romain, hello Tibor Thanks for your feedback. I had yesterday a very interesting conversation with Karl Heinz. He gave me some very informative links about deeply maven insights. Before I saw his talk on youtube I thought I have a good knowledge about maven ;-) now I was lerning a lot of new things.
He defined Maven as an plugin execution framework. I like to extend this definition: Maven is a process engine framework and define industrial defacto standards for the software development process. And with this idea in mind I think it could be great to define more workflows in a equal manner like the build lifecycle. The basic proposal is a first draft and I know some points are missing. I tried to keep the release process as simple as possible. Two positions in this definition was impotent for me. Often companies don't really have well structured release processes. For that reason I would be great to have a workable standard. I have a small Java project on GitHub, an sometimes I also deploy to maven central. If you do this the first time a bit complicated process. And publishing on maven central is also a release process. So I had the intention to define some ordered steps like in the build lifecycle to prepare and publish a release. Let me describe an example scenario for a release: After mvn build was successful executed all unit tests are passed, the sprint is finished and as build manager we want to release our artifact. Very important would be an option to take the results from the build lifecycle and prepare the release. As first we need to see that the planned artifact version is not exist in any configured public repository and the pom contains all mandatory information for publishing on maven central(validate). To secure a reproducible build, in a second step we enforce that no SNAPSHOT artifacts are involved, the correct maven version is used etc. (the existing enforcer plugin do a great job). After the preconditions are fine we can execute external acceptance tests like JGiven. In another step the JavaDoc got generated. the pgp plugin sing the artifacts and check that the public key is available. The SCM plugin create a tag for the released revision. Difficult parts are auto increment the version number and auto check the scm if the release is produced with the last revision of the code. This actions are by my experience a bit error prune. A release process could have some vocabulary like prepare, perform, deploy. This are just conventions, like it is used in the build lifecycle. To realize this idea, many already existing plugins can used, like the release plugin. In this proposal I was also not mentions external plugins to use like flyway, for database versioning and so on. A lot of things ar imaginable. In future more lifecycles or workflows could be possible. For example a deploy lifecycle and so on. And then maven transform from a plugin execution framework to a process management framework, like Jason van Zyl described in his book better build with maven. warm regards to all .marco On Fri, 2019-10-04 at 11:28 +0200, Romain Manni-Bucau wrote: > @Tibor: I agree merging both in one "super" command can be neat (I always > run both at once typically) but I disagree with last parts "skip the test" > - maven is also there to enforce tests as a good practise, if you don't > automatically test it you can configure maven to skip tests for the release > but it is at your own risk, can be fine or not - and "skip the deploy" - > here again you can configure maven to do it if you need but maven must > respect the build attached artifact. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le ven. 4 oct. 2019 à 11:22, Tibor Digana <tibordig...@apache.org> a écrit : > > > It would be worth to add a new goal called "release" to the > > maven-release-plugin which merges "prepare" and "perform". > > We developers in companies use both goals prepare and perform immediately > > together because for us two goals do not make sense. > > Two goals make sense for those who can wait days to start manual tests of > > the TAG but we don't! > > > > We are testing the JAR libraries beforehand and then we evaluate the > > quality/manual tests with SNAPSHOT whether it makes sense to start the > > release process in CLI. > > If there are web archives, the prepare phase would be enough because > > deployment in Nexus is useless nothing but the TAG itself and Continuous > > Delivery. > > > > On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <rmannibu...@gmail.com> > > wrote: > > > > > Hi Marco, > > > > > > I have 2 thoughts reading your post: > > > > > > 1. Should be enforced by an extension (sonatype plugin if target is > > > central?) > > > 2. It likely misses a few phases compared to maven release plugin which > > > validates the release can be done (including tests) and runs the tests on > > > the tag as well > > > > > > Now if 200 lines of xml can be replaced by a single extension I am +1000 > > > > on > > > that track > > > > > > Le ven. 4 oct. 2019 à 08:24, Marco Schulz <marco.sch...@outlook.com> a > > > écrit : > > > > > > > Hello Maven Dev & Community > > > > > > > > Sine a long time I thought, it would be cool to have a well defined > > > > process to > > > > prepare a release of an artifact and deploy it on mvn central. Now I > > > > got > > > a > > > > bit > > > > time to formulate a short proposal of my idea. I published a > > > > description > > > > of my > > > > thought on my bolg: > > > > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/ > > > > > > > > A poll is also created, may to see what other people think about it. > > > > Please feel > > > > free to leave also comments, every feedback is welcome. > > > > > > > > warm regards & thanks to the maven dev team for the great job they do. > > > > .marco (@ElmarDott) > > > > > > > > -- > > > > > > > > > > > > ____________________________________________________________________________ > > ____ > > > > Dipl. Inf. Marco Schulz (MSc) > > > > > > > > Expert for (WEB) Enterprise Applications > > > > - worldwide - > > > > + Project Manager + Consultant + Writer + Speaker + Trainer + > > > > > > > > > > > > > > > > [Contact]___________________________________________________________________ > > ____ > > > > > > > > WhatsApp : +52 (1) 221 200 61 37 :: Mexico > > > > Cell : +49 (0) 163 69 18 445 :: Germany > > > > E-Mail : marco.sch...@outlook.com > > > > > > > > Blog : https://enRebaja.wordpress.com > > > > twitter : https://twitter.com/ElmarDott > > > > tumblr : https://elmardott.tumblr.com > > > > facebook : https://www.facebook.com/elmar.dott > > > > > > > > > > > > > > > > [Services]__________________________________________________________________ > > ____ > > > > > > > > + Individual software development > > > > + Software Project Management > > > > + Build-, Configuration-, & Delivery Management > > > > + Release Management > > > > + Business Analysis > > > > + Software Architecture > > > > + Process Automation > > > > > > > > > > > > ____________________________________________________________________________ > > ____ > > > > This message is intended only for the use of the individual or entity > > > > to > > > > which > > > > it is addressed, and may contain information that is privileged, > > > > confidential > > > > and that may not be made public by law or agreement. If you are not the > > > > intended > > > > recipient or entity, you are hereby notified that any further > > > > dissemination, > > > > distribution or copying of this information is strictly prohibited. > > > > If you have received this communication in error, please contact us > > > > immediately > > > > and delete the message from your system. > > > > > > > >
