So, you are _rebuilding_ the project on each supported java (and run tests)? I am more in the "build once test many" as for example if you build on java8 and test on java8, what that proves if you release on java21 (so binary built with java21 is getting to central)?
On Sat, Sep 14, 2024, 14:28 Niels Basjes <ni...@basjes.nl> wrote: > I'm going to see if I can fix the RP issue here. > > ... still my original question remains ... : Is the observed behaviour of > the maven-release-plugin as intended? > > Niels > > On Sat, Sep 14, 2024 at 2:19 PM Niels Basjes <ni...@basjes.nl> wrote: > > > Hi, > > > > On Sat, Sep 14, 2024 at 12:36 PM Tamás Cservenák <ta...@cservenak.net> > > wrote: > > > >> Am not gonna answer your questions, just raise some more :) > >> > > > > Nice! > > > > > >> 1- You mention Trino and "no 22 buildchain". Well, Trino is also in RC > >> and as you say is Java 22, so how come? > >> > >> > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/trino/README.md > >> And Trino being Java 22, there have to be 22 toolchains available, no? > >> > > > > They use a JDK 22 only image ( > > docker.io/library/maven:3.9.9-eclipse-temurin-22 ) that I have not yet > > been able to extend with the other JDKs I need. > > I am looking into this direction if I can fix this! > > > > 2- The setup reminds me of some similar builds we have, for example > >> Resolver 2.x (master). > >> The "baseline" for Resolver 2.x is still Java 8, but there are modules > >> that are Java 11 or even 17. > >> > > > > Yes, similar to what my project has. Depending on the UDF the JDK > > toolchain is different. > > > > > >> (True, no 22). > > > > > > The key problem is that 22 has such a limited lifespan that the normal > > packages for systems like Ubuntu are not available. > > > > > >> Hence, to build a Resolver you need "highest Java" and > >> it is enforced, that is currently 21 > >> (I also like to stick to LTS Java versions). This way it is clear cut > >> what you need to build, moreover, if > >> if a user tries to build it with older Java, a meaningful error will > >> tell what the problem is and hopefully > >> help users to adapt (user required Java version). > >> > > > > Yes, I have that too. > > https://github.com/nielsbasjes/yauaa/blob/main/pom.xml#L518-L521 > > > > > >> 3- I still do not understand why "use max of required Java versions" > >> to build the project pattern would not > >> work for you? So in your case, you'd require Java 22 to build (as you > >> do have Java 22 module) but you > >> can still keep some "min" bytecode output (maven.compiler.release) for > >> most of the modules... > >> > > > > The key is that for the various UDFs I need all of the older JDKs too. > > If I build it with 22 then the META-INF/MANIFEST.MF will contain > > "Build-Jdk-Spec: 22" instead of "Build-Jdk-Spec: 21". > > This is different enough to fail reproducibility. > > > > Niels > > > > > > On Sat, Sep 14, 2024 at 12:12 PM Niels Basjes <ni...@basjes.nl> wrote: > >> > > >> > Hi, > >> > > >> > The problem I have is really a balancing act between several things I > >> want > >> > to have at the same time that are kinda incompatible. > >> > > >> > This is the actual usecase > >> > > >> > https://github.com/nielsbasjes/yauaa/blob/5501a47189e93f4917afddafbf766d024b907f0a/udfs/pom.xml#L90-L100 > >> > > >> > I have a library that does something useful and I want to be able to > run > >> > everywhere including systems that still need Java 8. > >> > During integration testing of the core library I run the tests under > >> JDK 8, > >> > 11, 17 and 21 (using toolchains) to ensure it actually works in all of > >> > those LTS JVMs. > >> > I do not like to rely on the non-LTS Java versions for building my > code > >> > with: too many updates. > >> > Because of some maven plugins I need to run the build under a recent > >> Java > >> > version, I have pinned that to the latest LTS: 21. > >> > > >> > I have several ready-to-run UDFs wrapping this functionality for > various > >> > engines to run in. Trino (https://trino.io/) is the only one that > >> requires > >> > Java 22 and this causes problems in my build. > >> > > >> > I also want my project to be reproducible so it is also here > >> > > >> > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content%2Fnl%2Fbasjes%2Fparse%2Fuseragent%2Fyauaa%2FREADME.md > >> > The reproducible site (of which I have written part of the code > together > >> > with Hervé Boutemy <https://github.com/hboutemy>) uses docker to do > the > >> > build. > >> > A toolchains build that also includes JDK 22 is not in there yet > (there > >> is > >> > no apt install for JDK 22 available because it is considered > unstable). > >> > As a consequence the reproducibility of my project has been off since > >> the > >> > Trino switch to JDK 22. > >> > > >> > So I have the module activated on the JDK 22+ version that maven runs > >> > under, but I have to run it under 21 to be reproducible. Hence I need > a > >> > different way of activating the profile. > >> > > >> > I have been looking if I can activate a profile if a toolchain version > >> is > >> > available but that is not yet a feature. > >> > Side question: Being able to activate an optional profile IF a > specific > >> > toolchain is available; Would that be a desirable feature in maven? > >> > > >> > Back to my original question: Is the observed behaviour of the > >> > maven-release-plugin as intended? > >> > > >> > Niels Basjes > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On Fri, Sep 13, 2024, 19:26 Tamás Cservenák <ta...@cservenak.net> > >> wrote: > >> > > >> > > Howdy, > >> > > > >> > > I am just shooting in the dark, but why not: > >> > > * activate profile on Java 22+ > >> > > * release on Java 22? > >> > > > >> > > (assuming the other module have maven.compiler.release=21 or some > >> > > reasonable value) > >> > > > >> > > HTH > >> > > T > >> > > > >> > > On Fri, Sep 13, 2024 at 11:41 AM Niels Basjes <ni...@basjes.nl> > >> wrote: > >> > > > > >> > > > Hi, > >> > > > > >> > > > I have in my project a maven module that is only activated if a > >> specific > >> > > > profile is active (by default it is not active). > >> > > > Side note: It is an part that requires Java 22, optional during > >> > > development > >> > > > and I do want to release it with the maven-release-plugin > >> > > > > >> > > > I have put this profile into both the list of profiles that need > to > >> be > >> > > > active during preparation and release (see sketch below). > >> > > > > >> > > > When I do "mvn release:prepare" it does not update the > >> module2/pom.xml > >> > > with > >> > > > the new version. > >> > > > I found that I need to explicitly activate it on the commandline > as > >> well > >> > > to > >> > > > activate it there too "mvn release:prepare -PActivateModule2" > >> > > > > >> > > > I expected this profile to be active during the entire prepare > phase > >> > > (i.e. > >> > > > including the "update the version" part). > >> > > > > >> > > > Is this an omission/bug or is this as intended? > >> > > > > >> > > > Niels Basjes > >> > > > > >> > > > <build> > >> > > > <plugins> > >> > > > <plugin> > >> > > > <groupId>org.apache.maven.plugins</groupId> > >> > > > <artifactId>maven-release-plugin</artifactId> > >> > > > <version>3.1.1</version> > >> > > > <configuration> > >> > > > <preparationProfiles>ActivateModule2</preparationProfiles> > >> > > > <releaseProfiles>ActivateModule2</releaseProfiles> > >> > > > </configuration> > >> > > > </plugin> > >> > > > </plugins> > >> > > > </build> > >> > > > > >> > > > <modules> > >> > > > <module>module1</module> > >> > > > </modules> > >> > > > > >> > > > <profiles> > >> > > > <profile> > >> > > > <id>ActivateModule2</id> > >> > > > <modules> > >> > > > <module>module2</module> > >> > > > </modules> > >> > > > </profile> > >> > > > </profiles> > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Best regards / Met vriendelijke groeten, > >> > > > > >> > > > Niels Basjes > >> > > > >> > > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> > > For additional commands, e-mail: users-h...@maven.apache.org > >> > > > >> > > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > -- > > Best regards / Met vriendelijke groeten, > > > > Niels Basjes > > > > > -- > Best regards / Met vriendelijke groeten, > > Niels Basjes >
