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
> > >
weekend to all
> > . marco
> >
> > Sent from Outlook Mobile<https://aka.ms/blhgte>
> >
> > ________
> > From: Romain Manni-Bucau
> > Sent: Saturday, October 5, 2019 2:06:27 AM
> > To: Maven Developers List
> > Cc: users
think about.
>
> rwgards and anice weekend to all
> . marco
>
> Sent from Outlook Mobile<https://aka.ms/blhgte>
>
>
> From: Romain Manni-Bucau
> Sent: Saturday, October 5, 2019 2:06:27 AM
> To: Maven Developers List
> Cc: us
weekend to all
. marco
Sent from Outlook Mobile<https://aka.ms/blhgte>
From: Romain Manni-Bucau
Sent: Saturday, October 5, 2019 2:06:27 AM
To: Maven Developers List
Cc: users
Subject: Re: Proposal: maven release lifecycle
I like the words but fail
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
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
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
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
@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
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
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
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
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:
13 matches
Mail list logo
