I've been investigating build failures with java-11-openjdk as
default, and a lot of those failures are attributable to issues with
javadoc generation, in particular with maven-javadoc-plugin.
It looks like maven-javadoc-plugin cannot do dependency resolution
correctly when run on java 11, and hence generating docs fails with
"package foo does not exist" and / or "unresolved symbol bar" errors,
I tried setting `-Xdoclint:none` when generating javadocs, but this
had no effect on the error.
However, I found an easy solution, which was to switch from using
maven-javadoc-plugin to xmvn-javadoc for generating the docs (by
flipping the existing bcond switch in javapackages-tools). From
previous experiments with this option, it only caused minor problems
with 1-2 packages.
With xmvn-javadoc, the number of packages that fails to build on java
11 was reduced drastically - from ~every package that has dependencies
declared in pom.xml to only those that actually have build issues with
java 11 (so, from about ~1000 failing packages to ~250).
Of those remaining ~250 packages, ~125 can be fixed by overriding java
compiler source / target values to 1.8, since they use target java <
1.6 in their build systems, which is no longer supported by javac 11.
I collected those "EasyFix" packages in this ticket:
The other half of build failures are mostly build issues that are
unrelated to the java 11 switch, and only a handful of packages looks
like it actually required code changes (yes, I looked at the build
logs for *all* the failed builds).
I've also set up a COPR for all packages that require java, with
java-1.8.0-openjdk, java-11-openjdk, and javapackages-tools with the
proposed changes + the switch to xmvn-javadoc:
It's set up to automatically run builds in the event commits are
pushed to dist-git or Pull Requests are filed for any of the packages
the COPR contains. So, for any changes to a package, it will
automatically get built against java 11 in the COPR, as well.
TL;DR: I propose we switch to xmvn-javadoc, since it fixes most of the
build issues I see with OpenJDK 11 by default.
Alternatively: If somebody can figure out how to fix generation of
javadocs with maven-javadoc-plugin, that would be great, as that would
be a smaller change than switching the javadoc generator entirely.
What do you think?
Good morning everybody,
I've collected all the scribbles, TODO items, and "need to do this
before this can happen" notes I had in various places (paper notes,
spreadsheets, etc.) in a murder ... erm, Kanban board on
teams.fedoraproject.org, and I hope that this will be useful to
organize and prioritize work on Java packaging in fedora:
I'm not sure how to add new members to this project, probably I need
to invite members with email address. I can send all members of the
@java-maint-sig group invite links. What do you think?
Hello, I made a review request for openjfx8: https://bugzilla.redhat.com/show_bug.cgi?id=1835350
It's the same package that openjfx. I create this review request because I would use the package openjfx for openjfx 11 and future LTS version and create a specific package for openjfx8 since Fedora 33. Please see https://bugzilla.redhat.com/show_bug.cgi?id=1801580.
Fedora <33 :
openjfx -> openjfx version 8
Fedora >=33 :
openjfx8 -> openjfx version 8
openjfx -> openjfx version 11
Please can you review my package?
Nicolas De Amicis
This past weekend I finally decided to jump off the cliff and attempt
to re-launch the Java SIG. It seems there's some interest in keeping
the Java stack maintained, it's just not focused or organized right
What we did when starting the Stewardship SIG seems to have worked out
pretty well, so I'm trying to follow in those footsteps here:
- new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied
by an old, unused bot account)
- new private mailing list: java-maint-sig (for RHBZ bugs - so,
possibly, also CVEs - hence, private)
- tracking project on pagure: https://pagure.io/java-maint-sig (for
maintenance scripts, tracking tickets, awesome package dashboards,
There's already a public fedora mailing list for Java (java-devel),
and and IRC channel (#fedora-java on freenode.net), which we will
continue to use. Sadly, the existing wiki page for the Java SIG is
hopelessly outdated, so I'm tempted to just scrap it and point readers
to the pagure tracking project once it's set up beyond a basic README
Major upcoming projects for the "new" Java Package Maintainers group include:
- managing OpenJDK 11 / Java 11 transition for hundreds of Java
packages in fedora 33
- starting to transition well-maintained Java packages from the
Stewardship SIG back into Java SIG
- possibly porting packages from gradle to maven to fix build issues
and broken dependencies
- transitioning from old java.net / JavaEE projects to the new ones
now under the eclipse-ee4j umbrella
I know that - among others - the PKI team, Neuro SIG, and Eclipse
maintainers depend on parts of the java stack for their packages, so I
hope that we can work together with them on these things, as well.
So, if you're interested, please consider joining this group effort.
I'll get new members set up with the FAS group / pagure project / mailing list.
Let's make this happen.
A bit of a tangential question:
Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> writes:
> So maybe just nuke the outdated parts (member lists, "state of affairs"
> content), and keep the rest?
My wiki-foo sucks. Is there some way to automatically generate a list of
members on the wiki from a FAS group?
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
Hello fellow java package maintainers!
We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk for F33. Please see
* if you have some java package, be aware that we are bumping JDK in rawhide
* Ensure your package builds and runs fine with JDK11 (see the
* there is special tooling ready for this, before mass rebuild is launched
** See https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild
* If you do not want Fedora rotten with JDK8 for ever, continue reading
We ran a preliminary mass rebuild of javastack in copr repo
https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all" instead of "25" at the
bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy & comp for build. You
can see, the result was quite dramatic:
1225 total; attempted to rebuild
483 failed; from those 191 are trivial failures (but if you fix it, there is no guarantee real
troubles are not hidden behind that)
556 orphans or dead or otherwise tragic so the build did not even start
I would kindly ask you to search yourself in this list: https://jvanek.fedorapeople.org/java11/people
If you are here, please check status of your package in https://jvanek.fedorapeople.org/java11/init
(pain text of https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds).
* If your package is "succeeded", congratulations nothing to do, and just keep en eye on JDK bump
* If there is "failed" but contains "- -" then it is probably orphan. If you wish to resurrect it,
please ensure it runs against JDK11 (see lower)
* If there is "failed" but failed in "seconds", then those packages failed so quickly, that the
build was in initial phases. That usually mean that you build with source/target lower then 1.6
JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to allow existence of
compact 1.8 packages alongside main javastack. See
https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version. Don't forget to
upstream the patch, or maybe it is enough to update to more fresh upstream release which supports
JDK11? it may happen, that after the fix, your build will fail in more terrible way (see below)
* If there is "failed", and its none of above, then your package simply failed. Very often the
scary error may be fixed by bump to latest upstream version. JDK 11 is out for several years.
Please, try to fix the package. Don't hesitate to ask on devel(a)fedoraproject.org or
java-devel(a)fedoraproject.org or directly to me jvanek(a)redhat.com. If you fix the fail, feel free to
share your fix, it may help others.
We are trying to gather the most common issues at
Feel free to enhance the page, or write us your case (possibly both with solution and without) so
we can add it here.
Debugging Your failures.
The copr repo we maintain, contains builds of java-11-openjdk as system JDK, javapackages-tools
honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains successfully rebuilt
packages. You can directly use this copr repo in several ways.
* first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your
build (select "all" instead of "25" at the bottom),
** Click its number, select chroot (currently fedora-32-x86_64 ) and check the logs. Main log is
* anything you push to rawhide, will automatically rebuild here in f32 chroot (we have a JDK in
rawhide broken a bit currently)
** It is the best approach. If you can fix your package in rawhide directly, without breaking the
rawhide too much, go for it
** If yo need to experiment, I have a mock config for you (generated from copr-cli mock-config
jvanek/java11 fedora-32-x86_64) which you can copy to your /etc/mock and use -
https://jvanek.fedorapeople.org/java11/jvanek-java11-fedora-32-x86_64.cfg . Eg:
sudo cp downloaded-fedora-32-x86_64.cfg /etc/mock/jvanek-java11-fedora-32-x86_64.cfg
# change spec, bump sources, apply patches
mock -r jvanek-java11-fedora-32-x86_64 *.src.rpm
Or any other packaging workflow you use, and you can use against the copr repo.
Thank you very much for your help, there are 500 failures, and 1000 java packagers, but only 2
active members of java sig. Without your help, the JDK bump will be very hard.
On behalf of Fedora java group