Howdy, Am not gonna answer your questions, just raise some more :) 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?
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. (True, no 22). 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). 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... Thanks T 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
