Re: OpenJDK 11 -- testing needed
Le 11/08/2018 à 18:33, Emmanuel Bourg a écrit : > Unfortunately we can't use the version of Gradle in experimental without > modifying gradle-debian-helper first. Gradle breaks the APIs used by > gradle-debian-helper, and the fix isn't trivial. I'm considering adding > a hook in Gradle that gradle-debian-helper could use to rewrite the > dependencies on the fly, that would decouple gradle-debian-helper from > the internal Gradle APIs and avoid similar breakage in the future. I > have no concrete implementation yet, so if you want to dive in, please > go ahead. Hi all, quick update from the Gradle front. I've played a bit with the concept of a hook and I now have a working solution. Once the implementation is cleaned up and fully tested I'll upload gradle and gradle-debian-helper with the new mechanism. This should unlock the upgrade of Gradle 4.4+, as well as ASM 6.1, OpenJFX 11, Spring 5.0... i.e. the key packages left upgrading to complete the Java 11 transition. Emmanuel Bourg
Re: OpenJDK 11 -- testing needed
Le 11/08/2018 à 17:56, Markus Koschany a écrit : > Can't we just use that and move on and package OpenJFX 11? > This is the package I would volunteer to work on. Unfortunately we can't use the version of Gradle in experimental without modifying gradle-debian-helper first. Gradle breaks the APIs used by gradle-debian-helper, and the fix isn't trivial. I'm considering adding a hook in Gradle that gradle-debian-helper could use to rewrite the dependencies on the fly, that would decouple gradle-debian-helper from the internal Gradle APIs and avoid similar breakage in the future. I have no concrete implementation yet, so if you want to dive in, please go ahead. Emmanuel Bourg
Re: OpenJDK 11 -- testing needed
Am 11.08.2018 um 17:27 schrieb Emmanuel Bourg: [...] > My next target will be Gradle 4.x because it's blocking OpenJFX 11 and > other packages which have been fixed upstream to work with Java 9+ but > require a more recent version of Gradle. We have to adapt > gradle-debian-helper to work with the new version. I plan to do that in > September. OpenJFX 11 is one of the most important packaging tasks for me at the moment, because without it all packaging work for PDFsam, Mediathekview and Netbeans come to naught. Kai-Chung has packaged Gradle 4.4 in experimental. Can't we just use that and move on and package OpenJFX 11? This is the package I would volunteer to work on. >> Maybe we should >> evaluate on a case-by-case basis what upstream projects intend to do >> before we start packaging removed functionality in separate packages. If >> it is not clear yet we can still use OpenJDK 8 for building the package. >> We just have to make sure it works with OpenJDK 11 at runtime. > > Let's review what is left fixing after the switch to OpenJDK 11. I still > hope we'll be able to avoid including OpenJDK 8 in Buster. > > >> We shouldn't put ourselves under pressure when even upstream projects >> have not decided yet how they want to support OpenJDK 11. > > I agree, but sometimes the decision will never be made, because the > project is no longer or barely maintained. And we can't keep OpenJDK 8 > forever either. We are between the hammer and the anvil :( It would be awesome if everything worked with OpenJDK 11 but I fear that won't be possible in time. At the moment we are at the forefront and many, many projects simply are not ready yet or hesitate because Java 8 is still supported (e.g. Netbeans). We don't have to keep it forever but we can keep OpenJDK 8 without security support for Buster and retire it next year when more projects hopefully will have embraced OpenJDK 11. signature.asc Description: OpenPGP digital signature
Re: OpenJDK 11 -- testing needed
Le 11/08/2018 à 09:37, Markus Koschany a écrit : > I'm a bit lost what is needed to switch to OpenJDK 11. Mostly JAX-WS at this point. I'm almost done, all the dependencies are ready thanks to the FTP masters who have kindly validated the packages during DebConf. I just have a last tricky Maven build issue to tackle and it's ok (jaxws turns pom artifacts into jars during the build and it confuses the dependency resolution of maven-debian-helper). We'll also have to package the CORBA replacement but that's less critical. I don't plan to work on this if someone wants to step up. My next target will be Gradle 4.x because it's blocking OpenJFX 11 and other packages which have been fixed upstream to work with Java 9+ but require a more recent version of Gradle. We have to adapt gradle-debian-helper to work with the new version. I plan to do that in September. > Maybe we should > evaluate on a case-by-case basis what upstream projects intend to do > before we start packaging removed functionality in separate packages. If > it is not clear yet we can still use OpenJDK 8 for building the package. > We just have to make sure it works with OpenJDK 11 at runtime. Let's review what is left fixing after the switch to OpenJDK 11. I still hope we'll be able to avoid including OpenJDK 8 in Buster. > We shouldn't put ourselves under pressure when even upstream projects > have not decided yet how they want to support OpenJDK 11. I agree, but sometimes the decision will never be made, because the project is no longer or barely maintained. And we can't keep OpenJDK 8 forever either. We are between the hammer and the anvil :( Emmanuel Bourg
Re: OpenJDK 11 -- testing needed
Le 20/07/2018 à 23:28, Emmanuel Bourg a écrit : > For a smooth transition I think we should switch the default JRE to > OpenJDK 11 once jaxws lands in sid. JAXB is also being removed from Java 11. We already have the src:jaxb package building the libraries, but it's missing the command line tools currently provided by the JDK (xjc and schemagen). We have a couple of packages calling xjc in debian/rules, they'll fail to build with Java 11 (jersey1 [1] and libhibernate-validator-java [2]). The missing maven-jaxb2-plugin has just been uploaded in May [3] by Jochen Sprickerhof, we can probably remove these hacks in debian/rules now. Emmanuel Bourg [1] https://sources.debian.org/src/jersey1/1.19.3-4/debian/rules/#L10 [2] https://sources.debian.org/src/libhibernate-validator-java/4.3.3-4/debian/rules/#L13 [3] https://tracker.debian.org/pkg/maven-jaxb2-plugin
Re: OpenJDK 11 -- testing needed
Le 31/07/2018 à 09:05, PICCA Frederic-Emmanuel a écrit : > I got this error report also [1] > > [1] > http://www.tango-controls.org/community/forum/c/general/installation/installing-jive-on-debian-stretch/?page=1 Thank you for pointing this out, I overlooked CORBA which is also removed from Java 11. I wrongly assumed it wasn't used but it is unfortunately [1]. It looks like we have to package the glassfish-corba project too [2]. Anyone volunteering to package this one? Emmanuel Bourg [1] https://codesearch.debian.net/search?q=import+org.omg.CORBA [2] https://github.com/javaee/glassfish-corba
Re: OpenJDK 11 -- testing needed
Le 31/07/2018 à 01:34, Matthias Klose a écrit : > this has now landed. Anything else to update before we do the switch? JAX-WS isn't fully there yet, there are a couple of packages missing, I'm still working on them. Emmanuel Bourg
Re: OpenJDK 11 -- testing needed
On 20.07.2018 23:28, Emmanuel Bourg wrote: > Le 20/07/2018 à 22:14, Markus Koschany a écrit : > >> I think the sooner we make OpenJDK 11 the default the better. This makes >> it more likely that we detect runtime issues before the freeze. I >> suppose there will be some FTBFS fallout again but I expect it to be in >> the same range when we switched from 9 to 10. > > Java 11 no longer contains JAX-WS (the javax.xml.ws and javax.jws > packages) and we don't have a replacement yet. This will affect at least > Spring, Tomcat and Netbeans. I started packaging the standalone JAX-WS > implementation [1], one new dependency is already in sid (saaj), another > one is in the NEW queue (jaxws-api), and 6 more have to be uploaded > (javax.jws, gmbal, gmbal-pfl, gmbal-commons, metro-policy and mimepull). > These packages are ready but need some polishing (proper package > description and copyright review). > > For a smooth transition I think we should switch the default JRE to > OpenJDK 11 once jaxws lands in sid. this has now landed. Anything else to update before we do the switch? Matthias
Re: OpenJDK 11 -- testing needed
Le 20/07/2018 à 22:14, Markus Koschany a écrit : > I think the sooner we make OpenJDK 11 the default the better. This makes > it more likely that we detect runtime issues before the freeze. I > suppose there will be some FTBFS fallout again but I expect it to be in > the same range when we switched from 9 to 10. Java 11 no longer contains JAX-WS (the javax.xml.ws and javax.jws packages) and we don't have a replacement yet. This will affect at least Spring, Tomcat and Netbeans. I started packaging the standalone JAX-WS implementation [1], one new dependency is already in sid (saaj), another one is in the NEW queue (jaxws-api), and 6 more have to be uploaded (javax.jws, gmbal, gmbal-pfl, gmbal-commons, metro-policy and mimepull). These packages are ready but need some polishing (proper package description and copyright review). For a smooth transition I think we should switch the default JRE to OpenJDK 11 once jaxws lands in sid. Emmanuel Bourg [1] https://github.com/javaee/metro-jax-ws
Re: OpenJDK 11 -- testing needed
Hi, Am 20.07.2018 um 21:43 schrieb Matthias Klose: > Hi, > > OpenJDK now is feature complete, and the package in unstable should migrate to > testing soonish. I didn't do any test rebuilds with 11 yet, but I think now > it's time to start doing these. Chris West did these for 10, but doesn't seem > to be active at the moment. Is there anybody volunteering to do test rebuilds > with 11, or should we just change the default and then start fixing issues? I think the sooner we make OpenJDK 11 the default the better. This makes it more likely that we detect runtime issues before the freeze. I suppose there will be some FTBFS fallout again but I expect it to be in the same range when we switched from 9 to 10. I'm also in favor of keeping OpenJDK 8 in Buster around as a fallback solution and a means to build multiple packages from source which will not be ready in time. One example is Netbeans 9 that requires OpenJDK 8 at build time but supports Java 9 and above at runtime. There are other packages where upstream continues to use Java 8 and I'm a bit tired to work around it. So in my opinion it makes sense to keep OpenJDK 8 in Buster for development and building packages as long as we make it clear that it is not supported at runtime and security-wise. You could just package the latest version right before we go into deep freeze and that's it. Markus signature.asc Description: OpenPGP digital signature
