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
