Marco, did you mean the SCM graph? Notice that companies have plenty of different ones. The plugin should be so much flexible that it would not have a problem to understand any of the graph and support it.
On Sat, Oct 5, 2019 at 4:15 PM Marco Schulz <marco.sch...@outlook.com> wrote: > I mention a ship lifecycle 😅 > > Sent from Outlook Mobile<https://aka.ms/blhgte> > > ________________________________ > From: Stephen Connolly <stephen.alan.conno...@gmail.com> > Sent: Saturday, October 5, 2019 2:49:51 AM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Proposal: maven release lifecycle > > 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 >
