java-devel December 2020

java-devel@lists.fedoraproject.org

6 participants
2 discussions

jansi 2.x and jline 3.x
by Jerry James 11 Jan '21

11 Jan '21

Hi all, I would like to keep jacop in Fedora. It is in danger of removal, due to the orphaning of scala. I've taken a look at keeping scala in Fedora, and updating it to its most recent version; see: https://copr.fedorainfracloud.org/coprs/jjames/scala/ One issue is that recent scala needs jline 3.x (we have 2.x in Rawhide), and jline 3.x needs jansi 2.x (we have 1.x in Rawhide). Neither is backwards compatible with its previous major version. I have made jansi 1.x/2.x and jline 2.x/3.x parallel installable, but there is still at least one issue. The current jansi package Provides: jansi = 1.18-5.fc33 mvn(org.fusesource.jansi:jansi) = 1.18 mvn(org.fusesource.jansi:jansi-project:pom:) = 1.18 mvn(org.fusesource.jansi:jansi:pom:) = 1.18 osgi(org.fusesource.jansi) = 1.18.0 The jansi2 package on COPR Provides: jansi2 = 2.1.0-1.fc34 jansi2(x86-64) = 2.1.0-1.fc34 libjansi.so()(64bit) mvn(org.fusesource.jansi:jansi) = 2.1.0 mvn(org.fusesource.jansi:jansi:pom:) = 2.1.0 osgi(org.fusesource.jansi) = 2.1.0 There is overlap between the Provides, albeit with different version numbers. How should this be handled? I guess that packages that need version 1.x would have to include "BuildRequires: jansi < 2" and "Requires: jansi"? Also, is it better to keep the existing jansi and jline packages, and add jansi2 and jline3 packages as I have done on COPR, or would it be better to add jansi1 and jline2 packages containing the current contents of jansi and jline, and then move jansi and jline to their latest versions? I appreciate any thoughts anyone has on the matter. Regards, -- Jerry James http://www.jamezone.org/

4 18

Macros controlling the source/target/release level flags for javac
by Jiri Vanek 06 Jan '21

06 Jan '21

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 M: +420775390109

5 19

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel December 2020