Re: [VOTE] Release Maven Resolver 1.9.12
Howdy, Just FTR, the 1.9.12 release staging repository changed to: https://repository.apache.org/content/repositories/maven-1965/ This is SAME source release as maven-1962 (vote original staging repository) as SHA512 shows, in fact, EVERY binary is identical (checksum wise) as well, given resolver build is reproducible. The only difference is named-locks Redisson bundle.zip as found by Herve (that was broken due to my environment). It is fixed and made reproducible as well (was fixed by fixing my own environment). Thanks T On Sat, Jun 17, 2023 at 9:57 AM Romain Manni-Bucau wrote: > Wouldnt it mean we are sure it was not consommed? Can we check it on nexus? > That said not a blocker today for me since most downstream binaries are not > reproducible anyway. > > Le sam. 17 juin 2023 à 08:56, Guillaume Nodet a écrit > : > > > Le sam. 17 juin 2023 à 02:50, Hervé Boutemy a > > écrit : > > > > > yes, same happened in 1.9.11: this is where I found this first, while > > > checking for Reproducible Central > > > > > > > > > > > > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/maven/resolver/maven-resolver/README.md > > > > > > > > > Yes, dropping your local repo would be nice to avoid such unexpected > > state > > > > > > Lately, umask has been a pain to Reproducible Builds: it gives much > > weight > > > to an environment aspect, with Linux distros changing their default > value > > > recently. > > > > > > > > > On Resolver 1.9.12, we have now multiple options: > > > 1. drop 1.9.12 and go to 1.9.13: looks overkill to me > > > 2. let 1.9.12 binaries as is: reasonable > > > 3. rebuild a new staging repository from Git tag: I'd love this one to > be > > > at least thought a little bit before saying no > > > > > > > Good idea. > > Even if the build was not reproducible, the vote has not been closed and > > the release has not been published, so we can actually rebuild the > > distributions (or even the tag, but that's a different topic). So I > don't > > think we should give it much thoughts, we should just do it :-) > > > > > > > > > > Explanation: > > > Given in reality the build itself is reproducible, but the reference > > build > > > has just one file broken by your desktop environment, it means that if > > you > > > "mvn -Papache-release deploy" from the Git tag, you'll get a new > staging > > > repository that will contain the same binaries (in particular the same > > > -source-release.ziip and its sha512), just with a fixed > > > maven-resolver-named-locks-redisson-1.9.12-bundle.zip > > > The real files that will be different are the .asc files > > > We could later decide if we release to Maven Central from current > > > maven-1962 or the new one > > > > > > Are you ready to try? (and discover one of the nice benefit of > > > Reproducible Builds...) > > > > > > Regards, > > > > > > Hervé > > > > > > Le vendredi 16 juin 2023, 19:23:14 CEST Tamás Cservenák a écrit : > > > > Found it: that above is my laptop, while I did (both) release on my > > > desktop: > > > > > > > > [cstamas@urnebes ~]$ cd > > .m2/repository-oss/org/objenesis/objenesis/3.3/ > > > > [cstamas@urnebes 3.3]$ ll > > > > total 68 > > > > -rw---. 1 cstamas cstamas 49423 2022 dec 15 objenesis-3.3.jar > > > > -rw---. 1 cstamas cstamas40 2022 dec 15 > > objenesis-3.3.jar.sha1 > > > > -rw---. 1 cstamas cstamas 3007 2022 dec 15 objenesis-3.3.pom > > > > -rw---. 1 cstamas cstamas40 2022 dec 15 > > objenesis-3.3.pom.sha1 > > > > -rw---. 1 cstamas cstamas 192 2022 dec 15 > _remote.repositories > > > > [cstamas@urnebes 3.3]$ > > > > > > > > Hence, the same should be true for 1.9.11 as well. Also, it seems > it's > > > time > > > > to nuke my local repo ;) > > > > > > > > Thanks > > > > T > > > > > > > > On Fri, Jun 16, 2023 at 7:16 PM Tamás Cservenák > > > > wrote: > > > > > Strange > > > > > > > > > > [cstamas@blondie ~]$ cd > > > .m2/repository-oss/org/objenesis/objenesis/3.3/ > > > > > [cstamas@blondie 3.3]$ ll > > > > > total 68 > > > > > -rw-r--r--. 1 cstamas cstamas 49423 dec 20 17.30 > objenesis-3.3.jar > > > > > -rw-r--r--. 1 cstamas cstamas40 dec 20 17.30 > > > objenesis-3.3.jar.sha1 > > > > > -rw-r--r--. 1 cstamas cstamas 3007 dec 20 17.30 > objenesis-3.3.pom > > > > > -rw-r--r--. 1 cstamas cstamas40 dec 20 17.30 > > > objenesis-3.3.pom.sha1 > > > > > -rw-r--r--. 1 cstamas cstamas 192 dec 20 17.30 > > _remote.repositories > > > > > [cstamas@blondie 3.3]$ > > > > > > > > > > Herve, while at this, please can you check 1.9.11 as well? IMHO > there > > > must > > > > > be the same issue present, or if not, am even more puzzled... > > > > > > > > > > T > > > > > > > > > > On Fri, Jun 16, 2023 at 7:13 PM Hervé Boutemy < > herve.bout...@free.fr > > > > > > > > > > > > > wrote: > > > > >> +1 > > > > >> > > > > >> notice that Reproducible Builds is NOT ok on 1 file: reference > build > > > done > > > > >> on > > > > >> *nix with JDK 17 and u
Re: [DISCUSS] POM model version
Le ven. 16 juin 2023, 19:20, Hervé Boutemy a écrit : > Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet a écrit : > > I think this is exactly what Hervé explains was rejected years ago. The > > assumption is that the POM v4 is "set in amber" and will never change, at > > least for the consumer side, i.e. defining dependencies. For the build > > side, it has to evolve, so the POM v5 will need a different schema url or > > version. But imho the goals are: > > * make sure we keep POM v4 the way it is to tools for consumers > > * allow some room for POM v5 on the build side > > > > However, the problem I see is that when you deploy a "pom" package, i.e. > a > > parent POM that may be used as a parent for other projects, we clearly > have > > a problem for which I do not really have a clear understanding how to > > solve. Let's assume this POM uses a POM v5 new feature, so that the > > semantic data carried by this POM can not be written with a POM v4. > Such a > > POM can not be uploaded to maven central in the v4 form, so it WILL break > > tools, but I don't really see any other way. > > > > So here's what I propose: > > * further trim down the consumer POM as it was envisioned years ago in > > [1] and [2] (the removed data will still be available for other tools to > > consume, see below) > > * we want to relax the constraints of the v4 pom schema a bit to be > able > > to validate the current build pom (where a few things are inferred) > > * for packaged artifacts, we will upload the consumer POM v4 as the > main > > POM and the normalized POM v4/v5 as an attached artifact > > * for the "pom" package, we will upload the normalized POM v4/v5 as the > > main POM (no consumer POM) > > > > In the short term we could then: > > * allow the definition of POM v4.x, i.e. small evolutions with a schema > > compatible to v4 (i.e. mostly new elements / attributes) that will give a > > bit of freedom to implement new stuff (i.e. we should start properly > > versioning it and communicate to the community that they will have to > adapt > > their tools) > > * when deploying the v4/v5 POM as the main POM (i.e. for pom packages), > > we could be smart enough to see if the POM requires non v4 features and > if > > that's not the case, upload it as a the lower version possible (i.e. POM > > v4), thereby minimizing disruption for other tools scanning central (and > > allow consumption with maven 3.x) > > Longer term: > > * define a POM v5+ schema (with GAV as attributes, etc...) > > > > Thoughts ? > ok for new attributes, that can simply added in POM v4.2 > > not ok for new elements: new elements are POM v5, with all the subtle > choices > to be done that you listed but I still did not have time to properly > evaluate, > and all the people who should really take time to evaluate. Notably those > who > will have to adapt publication rules to Maven Central for POM v5. > Well, v4.2 or V5, it's just a number. The point is that the url of the schema changes, so it's a new namespace. What is important is what we put behind this number. What I'd like to come up with is a policy for defining changes in the model. I don't think it would be a good idea to release a new POM version and keep it in amber forever as that was the case for 4.0.0. Given we would have a consumer POM set in amber, the goal is to have more freedom for the normalized POM that will be uploaded when deploying parents. Also, one thing to consider, is the use of alternatives syntax/language for the POM on the file system. If we want to minimize disruptions, we could choose to translate the POM on the file system to the normalized POM in a schema which would be compatible with the current schema. That's what polyglot has implemented and we could borrow the idea (as I demonstrated with the HOCON parser). So we'd have: * the amber'd POM 4.0.0 for consumer/flattened POMs (all packaged artifacts and BOMs) * the normalized new POM for deployed parent POMs (whatever version we want to give to it) * the build POM on the file system for which we could define alternative syntax Guillaume > Regards, > > Hervé > > > > > Guillaume > > > > [1] https://maven.apache.org/studies/consumer-pom/maven.html > > [2] > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > > > > Le mer. 14 juin 2023 à 08:48, Hunter C Payne > > > > a écrit : > > > Sorry for chiming in again but perhaps I might have an idea. The XSD > > > > > > schema that a POM uses is actually referenced from the POM. So in > essence > > > each POM carries with it what is needed to know to parse it. Perhaps > in > > > Maven 5 (or whichever version) we can require POM parsers to read and > use > > > the specific XSD schema referenced in the POM. That way you can have > more > > > room to try changes to the POM format. But there really should be a > > > mechanism for pushing POM changes downstream and XSD seems like a good > > > option for that. Sorry
Re: [VOTE] Release Maven Resolver 1.9.12
Wouldnt it mean we are sure it was not consommed? Can we check it on nexus? That said not a blocker today for me since most downstream binaries are not reproducible anyway. Le sam. 17 juin 2023 à 08:56, Guillaume Nodet a écrit : > Le sam. 17 juin 2023 à 02:50, Hervé Boutemy a > écrit : > > > yes, same happened in 1.9.11: this is where I found this first, while > > checking for Reproducible Central > > > > > > > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/maven/resolver/maven-resolver/README.md > > > > > > Yes, dropping your local repo would be nice to avoid such unexpected > state > > > > Lately, umask has been a pain to Reproducible Builds: it gives much > weight > > to an environment aspect, with Linux distros changing their default value > > recently. > > > > > > On Resolver 1.9.12, we have now multiple options: > > 1. drop 1.9.12 and go to 1.9.13: looks overkill to me > > 2. let 1.9.12 binaries as is: reasonable > > 3. rebuild a new staging repository from Git tag: I'd love this one to be > > at least thought a little bit before saying no > > > > Good idea. > Even if the build was not reproducible, the vote has not been closed and > the release has not been published, so we can actually rebuild the > distributions (or even the tag, but that's a different topic). So I don't > think we should give it much thoughts, we should just do it :-) > > > > > > Explanation: > > Given in reality the build itself is reproducible, but the reference > build > > has just one file broken by your desktop environment, it means that if > you > > "mvn -Papache-release deploy" from the Git tag, you'll get a new staging > > repository that will contain the same binaries (in particular the same > > -source-release.ziip and its sha512), just with a fixed > > maven-resolver-named-locks-redisson-1.9.12-bundle.zip > > The real files that will be different are the .asc files > > We could later decide if we release to Maven Central from current > > maven-1962 or the new one > > > > Are you ready to try? (and discover one of the nice benefit of > > Reproducible Builds...) > > > > Regards, > > > > Hervé > > > > Le vendredi 16 juin 2023, 19:23:14 CEST Tamás Cservenák a écrit : > > > Found it: that above is my laptop, while I did (both) release on my > > desktop: > > > > > > [cstamas@urnebes ~]$ cd > .m2/repository-oss/org/objenesis/objenesis/3.3/ > > > [cstamas@urnebes 3.3]$ ll > > > total 68 > > > -rw---. 1 cstamas cstamas 49423 2022 dec 15 objenesis-3.3.jar > > > -rw---. 1 cstamas cstamas40 2022 dec 15 > objenesis-3.3.jar.sha1 > > > -rw---. 1 cstamas cstamas 3007 2022 dec 15 objenesis-3.3.pom > > > -rw---. 1 cstamas cstamas40 2022 dec 15 > objenesis-3.3.pom.sha1 > > > -rw---. 1 cstamas cstamas 192 2022 dec 15 _remote.repositories > > > [cstamas@urnebes 3.3]$ > > > > > > Hence, the same should be true for 1.9.11 as well. Also, it seems it's > > time > > > to nuke my local repo ;) > > > > > > Thanks > > > T > > > > > > On Fri, Jun 16, 2023 at 7:16 PM Tamás Cservenák > > wrote: > > > > Strange > > > > > > > > [cstamas@blondie ~]$ cd > > .m2/repository-oss/org/objenesis/objenesis/3.3/ > > > > [cstamas@blondie 3.3]$ ll > > > > total 68 > > > > -rw-r--r--. 1 cstamas cstamas 49423 dec 20 17.30 objenesis-3.3.jar > > > > -rw-r--r--. 1 cstamas cstamas40 dec 20 17.30 > > objenesis-3.3.jar.sha1 > > > > -rw-r--r--. 1 cstamas cstamas 3007 dec 20 17.30 objenesis-3.3.pom > > > > -rw-r--r--. 1 cstamas cstamas40 dec 20 17.30 > > objenesis-3.3.pom.sha1 > > > > -rw-r--r--. 1 cstamas cstamas 192 dec 20 17.30 > _remote.repositories > > > > [cstamas@blondie 3.3]$ > > > > > > > > Herve, while at this, please can you check 1.9.11 as well? IMHO there > > must > > > > be the same issue present, or if not, am even more puzzled... > > > > > > > > T > > > > > > > > On Fri, Jun 16, 2023 at 7:13 PM Hervé Boutemy > > > > > > > > > wrote: > > > >> +1 > > > >> > > > >> notice that Reproducible Builds is NOT ok on 1 file: reference build > > done > > > >> on > > > >> *nix with JDK 17 and umask 022 > > > >> > > > >> the only issue is in > > > >> maven-resolver-named-locks-redisson-1.9.12-bundle.zip: > > > >> │--rw--- 2.0 unx49423 b- defN 23-Jun-16 13:32 > > objenesis-3.3.jar > > > >> │+-rw-r--r-- 2.0 unx49423 b- defN 23-Jun-16 13:32 > > objenesis-3.3.jar > > > >> it seems your local repository contains a objenesis-3.3.jar which is > > not > > > >> group > > > >> nor world wide readable > > > >> > > > >> Regards, > > > >> > > > >> Hervé > > > >> > > > >> Le vendredi 16 juin 2023, 15:57:43 CEST Tamás Cservenák a écrit : > > > >> > Howdy, > > > >> > > > >> > We solved 1 issue: > > > >> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628 > > > >> &ve>> > > > >> > rsion=12353340 > > > >> > > > > >> > There are still some issues in JIRA: > > > >> > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > >> > > >
