Not just that (def value): release plugin will NOT update the timestamp, if value is "inherited" from super POM, as opposed to "property is present in top level reactor POM". At least this is what I see from release sources, may be wrong. Still, the simplest is to have property in the project (parent).
Hence I think Maven warning is "cleanest" and also simplest thing we can do for now, especially as Maven4 needs to transparently build Maven3 projects.... Thanks T On Tue, Sep 24, 2024 at 11:13 PM Manfred Moser <manf...@simpligility.ca> wrote: > Fair enough .. that would be good as well. If we have no clear way for a > reasonable default value .. the default can be a warning with advice. > > manfred > > On 2024-09-24 2:06 p.m., Tamás Cservenák wrote: > > Just to tie to the previous message: > > we also discussed making ".mvn" directory _mandatory_ (from mvn4). > > > > So, essentially, if you have a Maven3 project, and you want to build it > > with Maven4, you MUST have a ".mvn" directory. You must create a ".mvn" > > directory. This "migration" is IMHO not biggie, as MANY Maven3 projects > > already have ".mvn" directory in the proper place. > > > > (otherwise, currently in Maven3 various code paths, like for start the > one > > in mvn script, then the one in MavenCli kicks in trying to "figure out" > > where is .mvn) > > > > IMHO the same stands for this: warn the user if build is NOT > reproducible, > > starting from Maven4. > > > > Thanks > > T > > > > On Tue, Sep 24, 2024 at 10:59 PM Tamás Cservenák <ta...@cservenak.net> > > wrote: > > > >> Howdy, > >> > >> we discussed this with Guillaume for a bit, and we got to a question: > >> why does Maven not warn IF build is not reproducible? (somehow similar > >> situation as with lack of .mvn directory) > >> > >> Yes, Maven always "does right", but in these two cases (date of the > build > >> and locating .mvn directory) the "heuristics" may be off, way off, and > is > >> better to be explicit. Hence, IMO Maven should just warn "this build is > not > >> reproducible (and you should do this and this to make it reproducible)". > >> > >> No magic, just warn the user. Probably from Maven4 > >> > >> Thanks > >> T > >> > >> > >> > >> On Tue, Sep 24, 2024 at 10:56 PM Herve Boutemy <hbout...@apache.org> > >> wrote: > >> > >>>> Or is the idea to have a *fixed* *default* timestamp for all builds? > >>> yes, this is the idea: there is no other option I can imagine to get a > >>> reproducible zip entries timestamp, whatever the precise value of the > >>> timestamp it is > >>> > >>> If anybody has any other algorithm idea (that supports wide reality of > >>> situation: not everything is built from Git, for example), I'm all > ears open > >>> > >>> if people want to discuss the exact default value chosen, we can also: > I > >>> don't care about this value, it just has to be defined > >>> > >>> Regards, > >>> > >>> Hervé > >>> > >>> On 2024/09/24 11:49:45 Ceki Gulcu wrote: > >>>> Hi Hervé, > >>>> > >>>> > >>>> In my opinion, the value of <project.build.outputTimestamp> should be > >>>> part of the pom.xml file and thus visible after the build. Otherwise, > >>>> how can the build be reproducible? > >>>> > >>>> Or is the idea to have a *fixed* *default* timestamp for all builds? > >>>> > >>>> -- > >>>> Ceki Gülcü > >>>> > >>>> Sponsoring SLF4J/logback/reload4j at > https://github.com/sponsors/qos-ch > >>>> > >>>> > >>>> > >>>> On 24/09/2024 11:21, Olivier Lamy wrote: > >>>>> Hi > >>>>> It looks like you have some comments on the PR :) > >>>>> I know it's been implemented as is for a long time now, but I wonder > I > >>>>> (and it looks like a few others) wonder if we could avoid this > >>>>> "random" build timestamp. > >>>>> > >>>>> > >>>>> On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy <herve.bout...@free.fr> > >>> wrote: > >>>>>> everything is in the title > >>>>>> > >>>>>> Jira issue is https://issues.apache.org/jira/browse/MNG-8258 > >>>>>> PR is https://github.com/apache/maven/pull/1726 > >>>>>> > >>>>>> WDYT about merging this PR as part of the Maven 4 global update? > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Hervé > >>>>>> > >>>>>> > >>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
