On 12/7/20 5:29 PM, Stephen Snow wrote:
That sounds reasonable, I watched the probelms last time from afar,
and didn't envy you.
90% of most terrible work was done by Fabio. All kudos to him!-)
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
I see. Definitely not in next jdk version. Although I recall this issue a bit do you ave
the bug id handy?
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.
You are right. Quarkus is fresh air in this area.
Jdk packaging as is now is not exactly healthy for container/flatpak world. The only
reasonable way is to have base images per JDK:(
Thanx a lto for ideas!
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
> 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
> 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:firstname.lastname@example.org> <mailto:email@example.com> M: +420775390109
_______________________________________________ java-devel mailing list --
> <mailto:firstname.lastname@example.org> To unsubscribe send an
email to java-devel-leave(a)lists.fedoraproject.org
<mailto:email@example.com> Fedora Code of Conduct:
> Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek(a)redhat.com
<mailto:firstname.lastname@example.org> M: +420775390109
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109