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
