Re: last review of Reproducible Builds proposal
Le 10/10/2019 à 19:28, Hervé BOUTEMY a écrit : > the only little mis-interpretation is that it is a pure build information, > then I don't see why this property would appear in a consumer POM Thank you for the clarification, that makes perfectly sense. And I now see the benefit of using a property that can be inherited. In a multi modules project it's only necessary to define the timestamp once in the root pom. Parent poms deployed to Maven Central will never include a timestamp and there is no risk of affecting other projects deriving from the pom. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: last review of Reproducible Builds proposal
Le jeudi 10 octobre 2019 17:17:07 CEST, vous avez écrit :
> Hi Hervé,
>
> >> - We already have maven.build.timestamp [1], so I wonder whether it
> >> should be maven.build.outputTimestap, too. Although one may argue that
> >> this *output* timestamp is a property of the project being built, not
> >> the Maven execution (in particular if the property becomes a POM element
> >> in POM version 5).
> >
> > you got it: it's project.* because it will be a POM element in POM v5
>
> Makes sense. Actually, my interpretation of the maven.* prefix (as being
> for the execution itself) seems to be wrong: A lot of core
> maven-*-plugins use this prefix for their properties, e.g.,
> maven.clean.failOnError, maven.install.skip, or maven.jar.forceCreation.
>
> Anyway, project.* makes more sense.
>
> >> Unfortunately, SimpleDateFormat or its java.time equivalents do not seem
> >> to have a format string for "seconds since the epoch", so we may want to
> >> make "seconds since the epoch" the default for
> >> project.build.outputTimestamp's format and only parse according to
> >> project.build.outputTimestamp.format when that property is indeed set.
> >>
> >> WDYT?
> >
> > the parsing from String to Date is done in maven-archiver code [1], then
> > we
> > can have the algorithm we want. We can even code that if the value is only
> > digits, it's parsed as "seconds since the epoch": no need to add the
> > format
> > property, the choice on one format over the other would be based on
> > effective value
>
> Yes, all digits -> "seconds since epoch" would be a reasonable heuristic.
>
> > What I don't get is: why do you absolutely want such a format?
> > And why do you want to use ${env.SOURCE_DATE_EPOCH}?
> > The proposal is about having "native" Reproducible Builds for Maven, then
> > not something added by an external rebuilder: it will be configured by
> > the original release.
>
> OK, I think I have misunderstood your use case:
>
> In the make-style builds I know that use SOURCE_DATE_EPOCH, some build
> step typically extracts a commit timestamp from, say, git and then sets
> SOURCE_DATE_EPOCH. This variable is then read and interpreted by the
> various built steps that follow. In other words, SOURCE_DATE_EPOCH is
> fed into the build from the outside.
>
> You seem to envision project.build.outputTimestamp to be hard-coded in
> the (consumer?) POM, i.e., not added from the outside (e.g., via
> ${env.SOURCE_DATE_EPOCH}). Is this interpretation correct?
yes
the only little mis-interpretation is that it is a pure build information,
then I don't see why this property would appear in a consumer POM
you can test it by building the fully working PoC:
https://github.com/apache/maven/tree/reproducible
>
> This means that updating the value would fall, e.g., to the
> maven-release-plugin (via [1]), so only releases would have a
> project.build.outputTimestamp (matching the release's time, not the
> timestamp of the corresponding commit, I assume).
the release plugin will update the release timestamp, yes.
But SNAPSHOTs would also have a timestamp just because they kept the timestamp
of previous release or they inherited from parent
>
> I would prefer if each commit would get an output timestamp matching the
> commit timestamp. Maybe one can use the buildnumber-maven-plugin [1] to
> achieve this, though. Setting to
> project.build.outputTimestamp would initialize that property during the
> "initialize" phase. Would that be early enough to be picked up by rest
> of the build.
imagine the commit is about a unit test, or documentation: changing the
timestamp would change the jar that has exactly the same .class content.
I think that updating the timestamp on every commit for SNAPSHOTs can seem
logical, but finally it would be counter-productive: that would break one
benefit of Reproducible Builds we can have for SNAPSHOTS is that we can use jar
hash to know if the code has changed or not = one use case that someone was
interested in when I had discussions with people (not on mailing list)
>
> Also, would a property set this way be part of the consumer POM?
I see this data only useful at build time: I don't know why it could be useful
at consume time
>
> I hope you can see what I am getting at, even if I might not have
> explained it very well.
I understand your solutions that look reasonably feasible, but not really
their objective.
But I appreciate the concrete discussion: maybe you have a use case that was
not defined before
Regards,
Hervé
>
> Best wishes,
>
> Andreas
>
> [1] <
> [2]
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[maven-compiler-plugin] Possibly bug: annotationProcessorPath assuming classifier=processor
Hello,
I just faced a problem here using maven 3.6.1 and java11. The
compiler-plugin is assuming the classifier of a declared
annotationProcessorPath as "processor".
I've set my pom using this:
>
>
>
> maven-compiler-plugin
> ${maven-compiler.version}
>
>
>
> io.dekorate
>
> kubernetes-annotations
> 0.9-SNAPSHOT
>
>
>
>
>
>
But I'm getting an error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project backend.core: Resolution of
> annotationProcessorPath dependencies failed: Missing:
> [ERROR] --
> [ERROR] 1) io.dekorate:kubernetes-annotations:jar:processor:0.9-SNAPSHOT
> [ERROR]
> [ERROR] Try downloading the file manually from the project website.
> [ERROR]
> [ERROR] Then, install it using the command:
> [ERROR] mvn install:install-file -DgroupId=io.dekorate
> -DartifactId=kubernetes-annotations -Dversion=0.9-SNAPSHOT
> -Dclassifier=processor -Dpackaging=jar -Dfile=/path/to/file
Am I missing something or is it a bug?
thanks,
Cristiano
Re: Surefire 3.0.0-M4 release?
I have to try to merge the fix because it avoids a situation when the VM hanged. It is very important for the users. The remaining fixes may go to M5. I will adjust Jira release notes, oki? I have time to cut the release, no problem. The only problem was to find some spare time for coding the fixes. I will try to be fast with the merge. On Thu, Oct 10, 2019 at 1:17 PM Olivier Lamy wrote: > We can release now 3.0.0-M4 and then release later with your remaining > fixes/new features. > As far I know we do not have a fix release content we can easily move the > remaining fixes to a 3.0.0-M5 > I'm happy to release it myself if you don't have time. > > On Thu, 10 Oct 2019 at 21:11, Tibor Digana wrote: > > > I understood the wish from JUnit5 fans e.g. Olivier Lamy but still we > have > > important fixes for the stability and it is hard to find new developers. > > I was thinking about this release/3.0.0-M4 and adding one more milestone > > too but there is fix on my PC that I have a problem to merge without new > > TCP/IP connector in Surefire. > > We still have TCP/IP connector in progress... > > > > On Thu, Oct 10, 2019 at 7:11 AM Enrico Olivelli > > wrote: > > > > > +1 > > > Enrico > > > > > > Il gio 10 ott 2019, 06:40 Romain Manni-Bucau > ha > > > scritto: > > > > > > > Anything user facing preventing to let it be a final? > > > > > > > > Anyway +1 to let fixes get out. > > > > > > > > Le jeu. 10 oct. 2019 à 02:53, Olivier Lamy a > écrit > > : > > > > > > > > > Hi, > > > > > It's now almost 10 months since last and around 30 issues fixed. > > > > > Maybe time for a new release? > > > > > Moving issues still open to 3.0.0-M5? > > > > > > > > > > cheers > > > > > -- > > > > > Olivier Lamy > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > > > > > > > > > > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy >
Standard http proxy environment variable evaluation
Hello,
By looking at this over the internet I don't find much informations.
Apparently the sole reliable way to configure proxy usage is trough
".m2/settings.xml" which annoys me when using CI/CD and docker behind proxies.
We do set standard environment variables for proxies in the builds that needs
it. But maven doesn't use these variables.
I would like to lookup if it would be possible to evaluate http_proxy or
https_proxy environment variables to fill in proxy settings.
I didn't find any opened Jira about that altought there are a lot ramblings
about using java properties ("-Dhttp.proxyHost" ...).
Any remarks, toughts about this?
Cédric
Re: Surefire 3.0.0-M4 release?
We can release now 3.0.0-M4 and then release later with your remaining fixes/new features. As far I know we do not have a fix release content we can easily move the remaining fixes to a 3.0.0-M5 I'm happy to release it myself if you don't have time. On Thu, 10 Oct 2019 at 21:11, Tibor Digana wrote: > I understood the wish from JUnit5 fans e.g. Olivier Lamy but still we have > important fixes for the stability and it is hard to find new developers. > I was thinking about this release/3.0.0-M4 and adding one more milestone > too but there is fix on my PC that I have a problem to merge without new > TCP/IP connector in Surefire. > We still have TCP/IP connector in progress... > > On Thu, Oct 10, 2019 at 7:11 AM Enrico Olivelli > wrote: > > > +1 > > Enrico > > > > Il gio 10 ott 2019, 06:40 Romain Manni-Bucau ha > > scritto: > > > > > Anything user facing preventing to let it be a final? > > > > > > Anyway +1 to let fixes get out. > > > > > > Le jeu. 10 oct. 2019 à 02:53, Olivier Lamy a écrit > : > > > > > > > Hi, > > > > It's now almost 10 months since last and around 30 issues fixed. > > > > Maybe time for a new release? > > > > Moving issues still open to 3.0.0-M5? > > > > > > > > cheers > > > > -- > > > > Olivier Lamy > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > > > > > > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Surefire 3.0.0-M4 release?
I understood the wish from JUnit5 fans e.g. Olivier Lamy but still we have important fixes for the stability and it is hard to find new developers. I was thinking about this release/3.0.0-M4 and adding one more milestone too but there is fix on my PC that I have a problem to merge without new TCP/IP connector in Surefire. We still have TCP/IP connector in progress... On Thu, Oct 10, 2019 at 7:11 AM Enrico Olivelli wrote: > +1 > Enrico > > Il gio 10 ott 2019, 06:40 Romain Manni-Bucau ha > scritto: > > > Anything user facing preventing to let it be a final? > > > > Anyway +1 to let fixes get out. > > > > Le jeu. 10 oct. 2019 à 02:53, Olivier Lamy a écrit : > > > > > Hi, > > > It's now almost 10 months since last and around 30 issues fixed. > > > Maybe time for a new release? > > > Moving issues still open to 3.0.0-M5? > > > > > > cheers > > > -- > > > Olivier Lamy > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > > >
