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(a)redhat.com> 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 JDK
No! 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(a)redhat.com
> <mailto:jvanek@redhat.com>> 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(a)redhat.com <mailto:jvanek@redhat.com>
>> <<mailto:jvanek@redhat.com>> M: +420775390109
>> _______________________________________________ java-devel mailing
>> list -- java-devel(a)lists.fedoraproject.org
>> <mailto:java-devel@lists.fedoraproject.org>
>> <<mailto:java-devel@lists.fedoraproject.org>> To unsubscribe send
>> an email to
>> java-devel-leave(a)lists.fedoraproject.org
>> <mailto:java-devel-leave@lists.fedoraproject.org>
>> <<mailto:java-devel-leave@lists.fedoraproject.org>> 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@lists.fedoraproj...
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com <mailto:jvanek@redhat.com> M: +420775390109