java-devel January 2021

java-devel@lists.fedoraproject.org

8 participants
6 discussions

Orphaning jython and friends
by Mat Booth 29 Jan '21

29 Jan '21

Hi all, I am orphaning jython and the following other Java packages that require or is required by it: jython eclipse-pydev netty os-maven-plugin xmlrpc -- Mat Booth http://fedoraproject.org/get-fedora

2 1

Introduction
by Akshat Sharma 19 Jan '21

19 Jan '21

Hi, My name is Akshat Sharma. I am an student and developer from India. I know java and want to contribute to fedora organization to explore the various capacities of java beyond my current use case. I am relatively new to open source and development in java but i will always try to contribute and learn to my capacity. Thank you Fas: akshatsharma5274

1 0

javapackages-tools auto Requires
by Markku Korkeala 18 Jan '21

18 Jan '21

Hi, I just got a bug report for clojure package that clojure is unable to start after installing it in a F33 container, it reports the following error: $ clojure /usr/bin/clojure: line 8: /usr/share/java-utils/java-functions: No such file or directory The /usr/bin/clojure is wrapper script generated with %jpackage_script macro. The clojure package explicit requirement for javapackages-tools package (which provides the /usr/share/java-utils/java-functions file) was removed little while ago, as I thought it would be auto required as stated in the Java howto: The requires generator also always generates Requires on java-headless and javapackages-tools. https://fedora-java.github.io/howto/latest/#dependency_handling Has this changed and should I add the explicit requirement for javapackages-tools ? Dependencies for clojure package are: $ rpm -qR clojure /usr/bin/bash java-headless >= 1:1.8 javapackages-filesystem mvn(org.clojure:core.specs.alpha) mvn(org.clojure:spec.alpha) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 Best regards, Markku Korkeala

3 3

Orphaning some packages
by Mat Booth 17 Jan '21

17 Jan '21

Hi all, I no longer have the bandwidth to maintain so many Eclipse plug-ins, so I just orphaned the following: eclipse-cdt eclipse-remote swt-chart freemarker Eclipse CDT and Linuxtools may still be installed through the Eclipse Marketplace by going to "Help" -> "Eclipse Marketplace" and searching for your favourite plug-ins there. -- Mat Booth http://fedoraproject.org/get-fedora

2 1

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 January 2021