On Sat 5 Oct 2019 at 08:14, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> I like the words but fail to see the missing pieces (understand actions to > do). > > Typically today when i release at work i use release plugin enriched with > github page deployment for the doc using antora + a ftp update of my server > output capture to have a mock backing openapi/swagger ui + docker ilage > deployment on docker hub + an intellij plugin deployment on jetbrains > marketplace etc...adding a flyway migration with a rolling update in a k8s > cluster is trivial (ops need to say yes though ;)). > > So technically it is verbose but doable. > > Custom lifecycle definition is not neat, custom build tasks require a build > hack or using groovy plugin but it works. Such a pity my ship-maven-plugin never gained traction > > Typically, an extension could enable all that based on convention, just > injecting needed plugins based on the file presence and values of the > distribution urls. > > This is why i ended up thinking we are more on 1. Sugar in release plugin > and 2. Maybe on a generic extension cretion (it replaces rigid lifecycle > for such cases these days due to their writing easiness) > > Am I missing something? > > Le sam. 5 oct. 2019 à 08:23, Marco Schulz <marco.sch...@outlook.com> a > écrit : > > > 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. > > > > > > > > > > > > > > > > > -- Sent from my phone
