No, I'm building it ONCE (which is a multirelease jar) and the integration tests run on many JVMs. Same as you describe.
Same as what you see here https://github.com/nielsbasjes/ToolChainsInCiBuilds/tree/main/MultiJDKInvokerTest Last year I refactored the Apache Avro build around that same model. Niels On Sat, Sep 14, 2024 at 2:42 PM Tamás Cservenák <ta...@cservenak.net> wrote: > 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 > > > -- Best regards / Met vriendelijke groeten, Niels Basjes
