Re: last review of Reproducible Builds proposal

Le 05/10/2019 à 19:52, Hervé BOUTEMY a écrit : > based on the feedback I got, I updated the proposal: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 > > The archives entries timestamp is now configured with > project.build.outputTimestamp property, in ISO-8601 format

Re: last review of Reproducible Builds proposal

Am 2019-10-05 um 22:10 schrieb Hervé BOUTEMY: Le samedi 5 octobre 2019 20:41:40 CEST, vous avez écrit : Am 2019-10-05 um 19:52 schrieb Hervé BOUTEMY: based on the feedback I got, I updated the proposal: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 The archives

Re: last review of Reproducible Builds proposal

>but >who really looks at the timestamp of entries in release zips/jars/tar.gz >honestly? Tomcat when it decides on what to send in the "Last-Modified" header. For instance, current Gradle does not allow to configure the timestamp, and for reproducible builds it always sets the timestamp to 0 or

Re: last review of Reproducible Builds proposal

with inheritance from parent, this question disappears: once parent pom has a timestamp value to have a reproducible release, child poms inherit the value and the reproducible feature changing the value in child is just a little improvement to get a timestamp that has more meaningful value, if

Re: last review of Reproducible Builds proposal

Hi Herve, I want to make sure we understand correctly. So. What you want to achieve with this property is to stick the property to one fixed value when the user has supposed the archive would have same content. And opposite, means that the property would be real when the content of the archive

Re: last review of Reproducible Builds proposal

Am 2019-10-05 um 19:52 schrieb Hervé BOUTEMY: based on the feedback I got, I updated the proposal: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 The archives entries timestamp is now configured with project.build.outputTimestamp property, in ISO-8601 format

last review of Reproducible Builds proposal

based on the feedback I got, I updated the proposal: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 The archives entries timestamp is now configured with project.build.outputTimestamp property, in ISO-8601 format 2019-10-02T08:04:00Z The shared

Re: [DISCUSS] Maven 3.7.0

Totally support java 8. There is nothing to discuss here. Not sure everyone realizes that, but it's 2019 already. Regarding the new features: 1) as you mentioned the new model, i think it will be good to introduce simple build graph balancing hints in the model. It is possible to examine

Re: Proposal: maven release lifecycle

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 wrote: > I mention a ship lifecycle  > >

Re: Proposal: maven release lifecycle

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

Re: Proposal: maven release lifecycle

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

Re: Proposal: maven release lifecycle

I mention a ship lifecycle  Sent from Outlook Mobile From: Stephen Connolly Sent: Saturday, October 5, 2019 2:49:51 AM To: Maven Developers List Subject: Re: Proposal: maven release lifecycle On Sat 5 Oct 2019 at 08:14, Romain

Re: Proposal: maven release lifecycle

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,

Re: Proposal: maven release lifecycle

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

Re: Proposal: maven release lifecycle

On Sat 5 Oct 2019 at 08:14, Romain Manni-Bucau 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 >

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

Re: Proposal: maven release lifecycle

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