That sounds reasonable, I watched the probelms last time from afar, and didn't envy you.
As for alternatives not working in SB or FCOS, I filed a bug against SB, which was closed since there was an upstream bug tracking it. AFAIK, it will be tackled at a later release. Though I am uncertain what later release is the intended target. In the meantime, I am embracing the container workflow more, this includes with my jdk dev projects. As I learn this way more, it does become easier. I guess I should expect a learning curve when I want to use near bleeding edge stuff. Also, the maturing of things like flatpaks, podman, etc... is happening constantly and thus things integrate better. Plus, platforms like Quarkus have gone a long way to making this container based workflow an easier transition than it would be without.
Regards,
Stephen
On Mon, Dec 7, 2020 at 17:15, Jiri Vanek <jvanek@xxxxxxxxxx> wrote:
On 12/7/20 5:12 PM, Stephen Snow wrote:Hello Jiri, I am not a packager for Fedora, but I am a user (of Fedora) who develops in Java at times. I assume you are referring to a replacement for alternatives (which doesn't work on Silverblue or Fedora CoreOS). The ability to switch between different JDKNo! Not At all! Alternatives are remaining same. This change is solemnly for build-time only. When we were bumping jdk form 8 to 11. 50% of chanes was to edit source/target flags of javac. I would like to avoid it in future... versions is a must for anyone doing Java programming for different organizations. So anything to make that a smoother operating workflow IMHO is welcome. Hm. How come alternatives do not work for SilverBlue and CoreOs?Stephen Snow On Mon, Dec 7, 2020 at 11:23, Jiri Vanek <jvanek@xxxxxxxxxx> wrote:Hi! I had risen this topic during jdk11 bump. but it somehow get lost. The idea is, to provide rpm macros, keeping the default source/target eventually - for jdk11 and up -the release - numbers for javac to use. Then to provide tooling, which will help packagers to use them - for ant and maven it should be simple. For others, probably nothing to do on our side, each packager will be able to patch/sed theirs builds as necessary (Still it will help a lot for future). I do not know how to provide them as default (except hardcoding in xmvn, and only allow to disable them on demand). This will smooth the bump to jdk17 in f36 really a lot. Thoughts? J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@xxxxxxxxxx <mailto:jvanek@xxxxxxxxxx> M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx <mailto:java-devel@xxxxxxxxxxxxxxxxxxxxxxx> To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx <mailto:java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/java-devel@xxxxxxxxxxxxxxxxxxxxxxx--Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@xxxxxxxxxx M: +420775390109
_______________________________________________ java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/java-devel@xxxxxxxxxxxxxxxxxxxxxxx
