java-devel May 2020

java-devel@lists.fedoraproject.org

10 participants
6 discussions

RFC: Switching from maven-javadoc-plugin to xmvn-javadoc
by Fabio Valentini 25 Jun '20

25 Jun '20

Good morning! 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, for example: https://copr.fedorainfracloud.org/coprs/g/java-maint-sig/java-11-default/bu… 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: https://pagure.io/java-maint-sig/issue/1 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: https://copr.fedorainfracloud.org/coprs/g/java-maint-sig/java-11-default/ 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? Fabio

4 3

Java Packaging Kanban Board
by Fabio Valentini 28 May '20

28 May '20

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: https://teams.fedoraproject.org/project/java-package-maintainer-sig/kanban 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? Fabio

1 0

Review Request: openjfx8 - Rich client application platform for Java
by Nicolas De Amicis 14 May '20

14 May '20

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. In short: Fedora <33 : openjfx -> openjfx version 8 Fedora >=33 : openjfx8 -> openjfx version 8 openjfx -> openjfx version 11 Please can you review my package? Thanks Nicolas De Amicis

2 1

Re-Launching the Java SIG
by Fabio Valentini 12 May '20

12 May '20

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 now. 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, etc.) 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 file. 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. Fabio

6 5

Re: Re-Launching the Java SIG
by Omair Majid 12 May '20

12 May '20

Hi, 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? Thanks, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0

1 0

F33 system wide change, java-11-openjdk as system jdk
by Jiri Vanek 01 May '20

01 May '20

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 https://fedoraproject.org/wiki/Changes/Java11 Short Story: * 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 https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/) * 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 Long Story: 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) 186 succeeded 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 https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_f… . 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 build.log.gz. * 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 fedpkg srpm 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. Thank You! On behalf of Fedora java group J.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel May 2020