You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Marco Schulz <ma...@outlook.com> on 2019/10/03 13:38:36 UTC
Proposal: maven release lifecycle
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.schulz@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.
Re: Proposal: maven release lifecycle
Posted by Hervé BOUTEMY <he...@free.fr>.
we talk about the maven-release-plugin, but I think that we should also talk
about the release profile = the way we extend the goals run during a non-
release build with a few additional goals on a release build
see for example the "apache-release" profile documentation of ASF parent
https://maven.apache.org/pom/asf/
By adding a new lifecycle, you would loose the sharing of most steps between
non-release and release builds
Like Karl Heinz, I really don't get the pain points you're trying to solve
Regards
Hervé
Le jeudi 3 octobre 2019, 17:04:02 CEST Karl Heinz Marbaise a écrit :
> Hi,
>
> first thanks...
>
> I have several question regarding your blog post ...
>
> Apart from beeing not accurate in some part I miss one very important thing:
>
> What is the real problem when doing a release via release plugin etc.
> which works well (I haven't said that it could be improved)...
>
> I want to know what the pain points are ?
>
>
> Kind regards
> Karl Heinz Marbaise
>
> On 03.10.19 15:38, Marco Schulz wrote:
> > 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)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Proposal: maven release lifecycle
Posted by Hervé BOUTEMY <he...@free.fr>.
we talk about the maven-release-plugin, but I think that we should also talk
about the release profile = the way we extend the goals run during a non-
release build with a few additional goals on a release build
see for example the "apache-release" profile documentation of ASF parent
https://maven.apache.org/pom/asf/
By adding a new lifecycle, you would loose the sharing of most steps between
non-release and release builds
Like Karl Heinz, I really don't get the pain points you're trying to solve
Regards
Hervé
Le jeudi 3 octobre 2019, 17:04:02 CEST Karl Heinz Marbaise a écrit :
> Hi,
>
> first thanks...
>
> I have several question regarding your blog post ...
>
> Apart from beeing not accurate in some part I miss one very important thing:
>
> What is the real problem when doing a release via release plugin etc.
> which works well (I haven't said that it could be improved)...
>
> I want to know what the pain points are ?
>
>
> Kind regards
> Karl Heinz Marbaise
>
> On 03.10.19 15:38, Marco Schulz wrote:
> > 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)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Proposal: maven release lifecycle
Posted by Tibor Digana <ti...@apache.org>.
I did not say that we skip test. I never skip the tests in prepare/perform.
Some colleagues do but for me it is good time to spend in the kitchen and
take a tea.
Our architecture was simply designed with isolated SCM projects, so the
dependencies are being downloaded into it and therefore I verify that what
would happen in SCM2 now if I compiled the lib in SCM1. Usually it is okay
because we have good ITs in SCM1 and we are cool devs ;-)
On Fri, Oct 4, 2019 at 11:28 AM Romain Manni-Bucau <rm...@gmail.com>
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 <ti...@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 <rmannibucau@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 <ma...@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.schulz@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.
> > > >
> > > >
> > >
> >
>
Re: Proposal: maven release lifecycle
Posted by Tibor Digana <ti...@apache.org>.
I did not say that we skip test. I never skip the tests in prepare/perform.
Some colleagues do but for me it is good time to spend in the kitchen and
take a tea.
Our architecture was simply designed with isolated SCM projects, so the
dependencies are being downloaded into it and therefore I verify that what
would happen in SCM2 now if I compiled the lib in SCM1. Usually it is okay
because we have good ITs in SCM1 and we are cool devs ;-)
On Fri, Oct 4, 2019 at 11:28 AM Romain Manni-Bucau <rm...@gmail.com>
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 <ti...@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 <rmannibucau@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 <ma...@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.schulz@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.
> > > >
> > > >
> > >
> >
>
Re: Proposal: maven release lifecycle
Posted by Tibor Digana <ti...@apache.org>.
Release lifecycle does not exist yet.
There's only "default", "clean", "site".
Therefore i would prefer to have this in CLI, i.e.
$ maven release
>> nowdays needs (release, js build, cloud deployment, gh-pages, etc...)
We cannot be technology specific but we can provide customization of the
release lifecycle.
The outcome of this discussion should be some frame-work as well as list of
items where we can agree and start writing Wiki page.
We do not have to go deeply "how" to do.
We should agree on "what" to do at least.
On Sat, Oct 5, 2019 at 4:08 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Personally Id like to keep current release lifecycle, it is the most
> generic one we can get but we need to let users create their own chain of
> mojo very easily in the pom.
>
> It is trivial to do with a custom descriptor and extension but it must be
> built in cause of nowdays needs (release, js build, cloud deployment,
> gh-pages, etc...)
>
> Le sam. 5 oct. 2019 à 15:18, Tibor Digana <ti...@apache.org> a
> écrit :
>
> > I have never seen a documentation for ship-maven-plugin.
> > It could be a good motivation for us.
> >
> > I can say for myself, my requirements are to the new lifecycle and plugin
> > goal release:release:
> > 1. executes phases from clean to deploy
> > 2. installation of "release" artifacts is skipped (snapshots are not
> > skipped)
> > 3. unit and integration tests are executed only once and not two times
> >
> > Tagging and SCM checkout are just fine.
> >
> > Second lifecycle for release without scm checkout and deployment. The
> test
> > would be executed once, tagging and both commit messages are the must.
> >
> > WDYT? How you would like to see the release lifecysle?
> > Notice that we should not say how the project should look like in the
> > customer. The customer may have reasons to use his project structures as
> > they are and the architecture too. So we should NOT define these
> > structures!
> >
> >
> > On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz <ma...@outlook.com>
> > wrote:
> >
> > > All this points are in my opinion an indicator that a release is a
> > complex
> > > process and very difficult to handle in just a plugin. To maintain all
> > that
> > > different points a relesaplugin will ver a ueber (god) plugin.
> > >
> > > Docker for example is another big toic we need to think about.
> > >
> > > rwgards and anice weekend to all
> > > . marco
> > >
> > > Sent from Outlook Mobile<https://aka.ms/blhgte>
> > >
> > > ________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > Sent: Saturday, October 5, 2019 2:06:27 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Cc: users <us...@maven.apache.org>
> > > Subject: Re: Proposal: maven release lifecycle
> > >
> > > 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.
> > >
> > > 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 <ma...@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 <ti...@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 <
> > > > rmannibucau@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.schulz@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.schulz@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.
> > > > > > > >
> > > > > > > >
> > > >
> > > >
> > >
> >
>
Re: Proposal: maven release lifecycle
Posted by Tibor Digana <ti...@apache.org>.
Release lifecycle does not exist yet.
There's only "default", "clean", "site".
Therefore i would prefer to have this in CLI, i.e.
$ maven release
>> nowdays needs (release, js build, cloud deployment, gh-pages, etc...)
We cannot be technology specific but we can provide customization of the
release lifecycle.
The outcome of this discussion should be some frame-work as well as list of
items where we can agree and start writing Wiki page.
We do not have to go deeply "how" to do.
We should agree on "what" to do at least.
On Sat, Oct 5, 2019 at 4:08 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Personally Id like to keep current release lifecycle, it is the most
> generic one we can get but we need to let users create their own chain of
> mojo very easily in the pom.
>
> It is trivial to do with a custom descriptor and extension but it must be
> built in cause of nowdays needs (release, js build, cloud deployment,
> gh-pages, etc...)
>
> Le sam. 5 oct. 2019 à 15:18, Tibor Digana <ti...@apache.org> a
> écrit :
>
> > I have never seen a documentation for ship-maven-plugin.
> > It could be a good motivation for us.
> >
> > I can say for myself, my requirements are to the new lifecycle and plugin
> > goal release:release:
> > 1. executes phases from clean to deploy
> > 2. installation of "release" artifacts is skipped (snapshots are not
> > skipped)
> > 3. unit and integration tests are executed only once and not two times
> >
> > Tagging and SCM checkout are just fine.
> >
> > Second lifecycle for release without scm checkout and deployment. The
> test
> > would be executed once, tagging and both commit messages are the must.
> >
> > WDYT? How you would like to see the release lifecysle?
> > Notice that we should not say how the project should look like in the
> > customer. The customer may have reasons to use his project structures as
> > they are and the architecture too. So we should NOT define these
> > structures!
> >
> >
> > On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz <ma...@outlook.com>
> > wrote:
> >
> > > All this points are in my opinion an indicator that a release is a
> > complex
> > > process and very difficult to handle in just a plugin. To maintain all
> > that
> > > different points a relesaplugin will ver a ueber (god) plugin.
> > >
> > > Docker for example is another big toic we need to think about.
> > >
> > > rwgards and anice weekend to all
> > > . marco
> > >
> > > Sent from Outlook Mobile<https://aka.ms/blhgte>
> > >
> > > ________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > Sent: Saturday, October 5, 2019 2:06:27 AM
> > > To: Maven Developers List <de...@maven.apache.org>
> > > Cc: users <us...@maven.apache.org>
> > > Subject: Re: Proposal: maven release lifecycle
> > >
> > > 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.
> > >
> > > 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 <ma...@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 <ti...@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 <
> > > > rmannibucau@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.schulz@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.schulz@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.
> > > > > > > >
> > > > > > > >
> > > >
> > > >
> > >
> >
>
Re: Proposal: maven release lifecycle
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Personally Id like to keep current release lifecycle, it is the most
generic one we can get but we need to let users create their own chain of
mojo very easily in the pom.
It is trivial to do with a custom descriptor and extension but it must be
built in cause of nowdays needs (release, js build, cloud deployment,
gh-pages, etc...)
Le sam. 5 oct. 2019 à 15:18, Tibor Digana <ti...@apache.org> a écrit :
> I have never seen a documentation for ship-maven-plugin.
> It could be a good motivation for us.
>
> I can say for myself, my requirements are to the new lifecycle and plugin
> goal release:release:
> 1. executes phases from clean to deploy
> 2. installation of "release" artifacts is skipped (snapshots are not
> skipped)
> 3. unit and integration tests are executed only once and not two times
>
> Tagging and SCM checkout are just fine.
>
> Second lifecycle for release without scm checkout and deployment. The test
> would be executed once, tagging and both commit messages are the must.
>
> WDYT? How you would like to see the release lifecysle?
> Notice that we should not say how the project should look like in the
> customer. The customer may have reasons to use his project structures as
> they are and the architecture too. So we should NOT define these
> structures!
>
>
> On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz <ma...@outlook.com>
> wrote:
>
> > All this points are in my opinion an indicator that a release is a
> complex
> > process and very difficult to handle in just a plugin. To maintain all
> that
> > different points a relesaplugin will ver a ueber (god) plugin.
> >
> > Docker for example is another big toic we need to think about.
> >
> > rwgards and anice weekend to all
> > . marco
> >
> > Sent from Outlook Mobile<https://aka.ms/blhgte>
> >
> > ________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > Sent: Saturday, October 5, 2019 2:06:27 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Cc: users <us...@maven.apache.org>
> > Subject: Re: Proposal: maven release lifecycle
> >
> > 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.
> >
> > 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 <ma...@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 <ti...@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 <
> > > rmannibucau@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.schulz@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.schulz@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.
> > > > > > >
> > > > > > >
> > >
> > >
> >
>
Re: Proposal: maven release lifecycle
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Personally Id like to keep current release lifecycle, it is the most
generic one we can get but we need to let users create their own chain of
mojo very easily in the pom.
It is trivial to do with a custom descriptor and extension but it must be
built in cause of nowdays needs (release, js build, cloud deployment,
gh-pages, etc...)
Le sam. 5 oct. 2019 à 15:18, Tibor Digana <ti...@apache.org> a écrit :
> I have never seen a documentation for ship-maven-plugin.
> It could be a good motivation for us.
>
> I can say for myself, my requirements are to the new lifecycle and plugin
> goal release:release:
> 1. executes phases from clean to deploy
> 2. installation of "release" artifacts is skipped (snapshots are not
> skipped)
> 3. unit and integration tests are executed only once and not two times
>
> Tagging and SCM checkout are just fine.
>
> Second lifecycle for release without scm checkout and deployment. The test
> would be executed once, tagging and both commit messages are the must.
>
> WDYT? How you would like to see the release lifecysle?
> Notice that we should not say how the project should look like in the
> customer. The customer may have reasons to use his project structures as
> they are and the architecture too. So we should NOT define these
> structures!
>
>
> On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz <ma...@outlook.com>
> wrote:
>
> > All this points are in my opinion an indicator that a release is a
> complex
> > process and very difficult to handle in just a plugin. To maintain all
> that
> > different points a relesaplugin will ver a ueber (god) plugin.
> >
> > Docker for example is another big toic we need to think about.
> >
> > rwgards and anice weekend to all
> > . marco
> >
> > Sent from Outlook Mobile<https://aka.ms/blhgte>
> >
> > ________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > Sent: Saturday, October 5, 2019 2:06:27 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Cc: users <us...@maven.apache.org>
> > Subject: Re: Proposal: maven release lifecycle
> >
> > 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.
> >
> > 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 <ma...@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 <ti...@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 <
> > > rmannibucau@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.schulz@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.schulz@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.
> > > > > > >
> > > > > > >
> > >
> > >
> >
>
Re: Proposal: maven release lifecycle
Posted by Tibor Digana <ti...@apache.org>.
I have never seen a documentation for ship-maven-plugin.
It could be a good motivation for us.
I can say for myself, my requirements are to the new lifecycle and plugin
goal release:release:
1. executes phases from clean to deploy
2. installation of "release" artifacts is skipped (snapshots are not
skipped)
3. unit and integration tests are executed only once and not two times
Tagging and SCM checkout are just fine.
Second lifecycle for release without scm checkout and deployment. The test
would be executed once, tagging and both commit messages are the must.
WDYT? How you would like to see the release lifecysle?
Notice that we should not say how the project should look like in the
customer. The customer may have reasons to use his project structures as
they are and the architecture too. So we should NOT define these structures!
On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz <ma...@outlook.com>
wrote:
> All this points are in my opinion an indicator that a release is a complex
> process and very difficult to handle in just a plugin. To maintain all that
> different points a relesaplugin will ver a ueber (god) plugin.
>
> Docker for example is another big toic we need to think about.
>
> rwgards and anice weekend to all
> . marco
>
> Sent from Outlook Mobile<https://aka.ms/blhgte>
>
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Saturday, October 5, 2019 2:06:27 AM
> To: Maven Developers List <de...@maven.apache.org>
> Cc: users <us...@maven.apache.org>
> Subject: Re: Proposal: maven release lifecycle
>
> 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.
>
> 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 <ma...@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 <ti...@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 <
> > rmannibucau@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.schulz@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.schulz@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.
> > > > > >
> > > > > >
> >
> >
>
Re: Proposal: maven release lifecycle
Posted by Tibor Digana <ti...@apache.org>.
I have never seen a documentation for ship-maven-plugin.
It could be a good motivation for us.
I can say for myself, my requirements are to the new lifecycle and plugin
goal release:release:
1. executes phases from clean to deploy
2. installation of "release" artifacts is skipped (snapshots are not
skipped)
3. unit and integration tests are executed only once and not two times
Tagging and SCM checkout are just fine.
Second lifecycle for release without scm checkout and deployment. The test
would be executed once, tagging and both commit messages are the must.
WDYT? How you would like to see the release lifecysle?
Notice that we should not say how the project should look like in the
customer. The customer may have reasons to use his project structures as
they are and the architecture too. So we should NOT define these structures!
On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz <ma...@outlook.com>
wrote:
> All this points are in my opinion an indicator that a release is a complex
> process and very difficult to handle in just a plugin. To maintain all that
> different points a relesaplugin will ver a ueber (god) plugin.
>
> Docker for example is another big toic we need to think about.
>
> rwgards and anice weekend to all
> . marco
>
> Sent from Outlook Mobile<https://aka.ms/blhgte>
>
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Saturday, October 5, 2019 2:06:27 AM
> To: Maven Developers List <de...@maven.apache.org>
> Cc: users <us...@maven.apache.org>
> Subject: Re: Proposal: maven release lifecycle
>
> 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.
>
> 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 <ma...@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 <ti...@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 <
> > rmannibucau@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.schulz@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.schulz@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.
> > > > > >
> > > > > >
> >
> >
>
Re: Proposal: maven release lifecycle
Posted by Marco Schulz <ma...@outlook.com>.
All this points are in my opinion an indicator that a release is a complex process and very difficult to handle in just a plugin. To maintain all that different points a relesaplugin will ver a ueber (god) plugin.
Docker for example is another big toic we need to think about.
rwgards and anice weekend to all
. marco
Sent from Outlook Mobile<https://aka.ms/blhgte>
________________________________
From: Romain Manni-Bucau <rm...@gmail.com>
Sent: Saturday, October 5, 2019 2:06:27 AM
To: Maven Developers List <de...@maven.apache.org>
Cc: users <us...@maven.apache.org>
Subject: Re: Proposal: maven release lifecycle
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.
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 <ma...@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 <ti...@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 <
> rmannibucau@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 <ma...@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.schulz@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.
> > > > >
> > > > >
>
>
Re: Proposal: maven release lifecycle
Posted by Marco Schulz <ma...@outlook.com>.
All this points are in my opinion an indicator that a release is a complex process and very difficult to handle in just a plugin. To maintain all that different points a relesaplugin will ver a ueber (god) plugin.
Docker for example is another big toic we need to think about.
rwgards and anice weekend to all
. marco
Sent from Outlook Mobile<https://aka.ms/blhgte>
________________________________
From: Romain Manni-Bucau <rm...@gmail.com>
Sent: Saturday, October 5, 2019 2:06:27 AM
To: Maven Developers List <de...@maven.apache.org>
Cc: users <us...@maven.apache.org>
Subject: Re: Proposal: maven release lifecycle
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.
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 <ma...@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 <ti...@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 <
> rmannibucau@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 <ma...@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.schulz@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.
> > > > >
> > > > >
>
>
Re: Proposal: maven release lifecycle
Posted by Tibor Digana <ti...@apache.org>.
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 <ma...@outlook.com>
wrote:
> I mention a ship lifecycle 😅
>
> Sent from Outlook Mobile<https://aka.ms/blhgte>
>
> ________________________________
> From: Stephen Connolly <st...@gmail.com>
> Sent: Saturday, October 5, 2019 2:49:51 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Proposal: maven release lifecycle
>
> On Sat 5 Oct 2019 at 08:14, Romain Manni-Bucau <rm...@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 <ma...@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 <ti...@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 <
> > > rmannibucau@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.schulz@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.schulz@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
>
Re: Proposal: maven release lifecycle
Posted by Marco Schulz <ma...@outlook.com>.
I mention a ship lifecycle 😅
Sent from Outlook Mobile<https://aka.ms/blhgte>
________________________________
From: Stephen Connolly <st...@gmail.com>
Sent: Saturday, October 5, 2019 2:49:51 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Proposal: maven release lifecycle
On Sat 5 Oct 2019 at 08:14, Romain Manni-Bucau <rm...@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 <ma...@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 <ti...@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 <
> > rmannibucau@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.schulz@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.schulz@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
Re: Proposal: maven release lifecycle
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 5 Oct 2019 at 08:14, Romain Manni-Bucau <rm...@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 <ma...@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 <ti...@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 <
> > rmannibucau@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.schulz@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.schulz@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
Re: Proposal: maven release lifecycle
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
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 <ma...@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 <ti...@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 <
> rmannibucau@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 <ma...@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.schulz@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.
> > > > >
> > > > >
>
>
Re: Proposal: maven release lifecycle
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
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 <ma...@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 <ti...@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 <
> rmannibucau@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 <ma...@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.schulz@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.
> > > > >
> > > > >
>
>
Re: Proposal: maven release lifecycle
Posted by Marco Schulz <ma...@outlook.com>.
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 <ti...@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 <rm...@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 <ma...@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.schulz@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.
> > > >
> > > >
Re: Proposal: maven release lifecycle
Posted by Marco Schulz <ma...@outlook.com>.
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 <ti...@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 <rm...@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 <ma...@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.schulz@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.
> > > >
> > > >
Re: Proposal: maven release lifecycle
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@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 <ti...@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 <rm...@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 <ma...@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.schulz@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.
> > >
> > >
> >
>
Re: Proposal: maven release lifecycle
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@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 <ti...@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 <rm...@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 <ma...@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.schulz@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.
> > >
> > >
> >
>
Re: Proposal: maven release lifecycle
Posted by Tibor Digana <ti...@apache.org>.
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 <rm...@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 <ma...@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.schulz@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.
> >
> >
>
Re: Proposal: maven release lifecycle
Posted by Tibor Digana <ti...@apache.org>.
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 <rm...@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 <ma...@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.schulz@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.
> >
> >
>
Re: Proposal: maven release lifecycle
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ma...@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.schulz@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.
>
>
Re: Proposal: maven release lifecycle
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
first thanks...
I have several question regarding your blog post ...
Apart from beeing not accurate in some part I miss one very important thing:
What is the real problem when doing a release via release plugin etc.
which works well (I haven't said that it could be improved)...
I want to know what the pain points are ?
Kind regards
Karl Heinz Marbaise
On 03.10.19 15:38, Marco Schulz wrote:
> 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)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Proposal: maven release lifecycle
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
first thanks...
I have several question regarding your blog post ...
Apart from beeing not accurate in some part I miss one very important thing:
What is the real problem when doing a release via release plugin etc.
which works well (I haven't said that it could be improved)...
I want to know what the pain points are ?
Kind regards
Karl Heinz Marbaise
On 03.10.19 15:38, Marco Schulz wrote:
> 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)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Proposal: maven release lifecycle
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ma...@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.schulz@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.
>
>