java-devel October 2021

java-devel@lists.fedoraproject.org

10 participants
10 discussions

Unable to execute shade-jar
by Didik Supriadi 25 Oct '21

25 Oct '21

Hi, I was trying to execute `shade-jar` and got this output: $ shade-jar javax.activation jakarta.activation /usr/share/java/jakarta-activation/jakarta.activation.jar lib/shaded-jakarta.activation.jar /usr/bin/shade-jar: Unable to execute objectweb-asm3-processor. /usr/bin/shade-jar: Make sure that objectweb-asm3 is installed. but objectweb-asm3 is currently unmaintained. [1] [1] https://src.fedoraproject.org/rpms/objectweb-asm3 -- Regards, Didik Supriadi (he/him) https://getfedora.org

1 0

Allowing Class-Path in MANIFEST.MF
by Mikolaj Izdebski 24 Oct '21

24 Oct '21

Hello, I would like to propose allowing Class-Path attribute in JAR manifests, at least in some cases. Currently Java Packaging Guidelines [1] forbids Class-Path attributes in JAR manifests. However there are certain cases when Class-Path can be very useful. One such example I find it useful for is executable JARs that can be symlinked from %{_libexecdir} and ran without a need for wrapper shell scripts. Such JAR files are marked as executable and start with a shebang line, which is treated as leading garbage and therefore ignored by JAR/ZIP readers. When such JARs have dependencies it's useful to be able to refer to them via Class-Path manifest attribute. What do you think about allowing Class-Path manifest attribute? Can it be allowed in any case, or in some cases only? [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/

3 4

Trying to resurrect truth
by Orion Poplawski 16 Oct '21

16 Oct '21

I'm trying to resurrect the google "truth" package. I have a 0.42 branch here: https://src.fedoraproject.org/fork/orion/rpms/truth/tree/0.42 But the javadoc fails to build with: [INFO] -------------------< com.google.truth:truth-parent >-------------------- [INFO] Building Truth (Parent) 0.42 [7/6] [INFO] --------------------------------[ pom ]--------------------------------- [INFO] [INFO] --- xmvn-mojo:4.0.0:install (default-cli) @ truth-parent --- [INFO] [INFO] --- xmvn-mojo:4.0.0:javadoc (default-cli) @ truth-parent --- /home/orion/fedora/truth/truth-release_0_42/extensions/proto/target/generated-sources/annotations/com/google/common/truth/extensions/proto/AutoValue_FluentEqualityConfig.java:11: error: cannot find symbol import javax.annotation.Generated; ^ symbol: class Generated location: package javax.annotation any advice as to how to proceed would be helpful. These are generate source files. I've tried disabling maven-plugin-javadoc and excluding sources in various ways to no effect. Thanks! -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

6 7

JNI shared objects in %{_prefix}/lib
by Mikolaj Izdebski 11 Oct '21

11 Oct '21

Hello, I want to propose updating Java Packaging Guidelines [1] to allow installation of JNI shared objects in %{_prefix}/lib/%{name} or in %{_libdir}/%{name}, according to packager preference. %{_libdir} expands to either /usr/lib or /usr/lib64 (depending on system architecture), while %{_prefix}/lib always expands to /usr/lib. To see what %{_libdir} expands to on each platform, you can run: grep %_libdir -r /usr/lib/rpm/platform/ Currently Java Packaging Guidelines require all packages to install JNI shared objects in %{_libdir}/%{name}, which causes issues for noarch packages that want to refer to such shared objects. For example Maven needs to install a symlink to libjansi.so. Since Maven is a noarch package, the symlink must technically point to one fixed location, but libjansi.so ought to be installed in different locations on different architectures. Moving libjansi.so to one location across all architectures solves this problem. An alternative solution involves usage of a ghost symlink manipulated by scriplets, which in my opinion is an inferior solution. Java has been granted multilib exemption by FESCo [2], therefore I would like to allow installation of JNI shared objects in %{_prefix}/lib/%{name} or %{_libdir}/%{name}. Does anyone have any objections or feedback before I go with this request to FPC? [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ [2] https://pagure.io/fesco/issue/961

5 7

Updated Java package review template
by Mikolaj Izdebski 10 Oct '21

10 Oct '21

Hello, I've just updated Java package review template [1] on the wiki to match current Package Review Guidelines [2] and Java Packaging Guidelines [3]. The template was severely outdated - the last change was more than 10 years ago. If you find any issues with the new version please let me know, or fix them directly on the wiki. -- Mikolaj Izdebski [1] https://fedoraproject.org/wiki/Java_review_template [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/

1 0

Remittance Advise
by Phelan＠fedoraproject.org 07 Oct '21

07 Oct '21

1 0

Cleaning up SIGs/Java wiki page
by Mikolaj Izdebski 07 Oct '21

07 Oct '21

Hello, I'd like to clean up Java SIG wiki page [1]. Besides removing or fixing obviously outdated or incorrect information I would also like to remove the list of members. It is severely outdated and serves no purpose any longer. In particular the list of active packager sponsors interested in Java can nowadays be found at [2]. Are there any objections to removing the list of Java SIG members from the wiki page? [1] https://fedoraproject.org/wiki/SIGs/Java [2] https://docs.pagure.org/fedora-sponsors/interests#Java

2 4

Bringing back Java package search engine
by Mikolaj Izdebski 07 Oct '21

07 Oct '21

Hello, Is anyone interested in having a web page that allows searching for Java classes within RPM packages across different Fedora releases? There is an existing working code [1], it just needs to be deployed somewhere and maintained. I can run the site if anyone is interested in using it. -- Mikolaj Izdebski [1] https://github.com/fedora-java/java-deptools

1 0

Orphaning maven-indexer
by Mat Booth 04 Oct '21

04 Oct '21

Hi all, I am orphaning maven-indexer. I only needed it for Eclipse M2E, which is no longer in Fedora. It currently fails to install because of missing dep on Lucene, which is also no longer in Fedora. I'm not aware of any other consumers of maven-indexer. Thanks -- Mat Booth http://fedoraproject.org/get-fedora

1 0

Empowering Fedora Java
by Peter Boy 03 Oct '21

03 Oct '21

On the Fedora devel list, 2 days ago Jhordy M. Caceres Guerra brought up the old thread "Re-Launching the Java Sig" again (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…) Jhordy would like to contribute to Fedora Java. The offer has so far remained without response, as in so many other cases that I have read over the past months. I would like to take this as an opportunity to discuss Fedora Java reorganization again here on the list. Additionally, we had the standard invitation to the java-maint-sig meeting yesterday, scheduled for === tomorrow, 2021-09-16 15:00 UTC fedora-meeting-2(a)irclibera.chat. === This regular meeting schedule was not used for half a year or so. Maybe we can use it (more or less off-topic) for discussion of further development of Fedora Java. I’ll be lurking around. === Some details and proposals. === Fabio had come up with a plan composed of several steps to reorganize and revitalize the Fedora Java stack. Some of it is realized (e.g. the java-maint-sic), some not (e.g. update of the deprecated java-sig wiki page). The biggest success is that with all the adversities in java packaging we have a stabilized Fedora Java core platform. The next urgent step, in my opinion, is to update and improve information materials and documentation, followed by a community building process based on it. I can offer to do the writing. I have already done that for the (successful) rebooting of the Fedora Server Working Group. But I needed support, information and ideas from the other sig members or people otherwise involved in Fedora Java, especially from the java-maint-sig that keeps the whole thing going. Otherwise, it makes no sense. Some ideas about topics documentation/information material should cover - what provides current java core stack (i.e. what is handled ( and guaranteed) by java-maint-sig) - (very) short description of what exactly are the issues with Fedora java packaging (maven, dependencies, no binary libs) - what are the current plans of java-maint-sig - what other software is available as Fedora package (if there is anything at all outside of java-maint-sig) - how to handle software whose packages have been removed - informal package sources (copr) - how install and configure third party software (general hints related to Fedora's way for Java) - for which tasks we are looking for contributors - how to proceed if you want to add a package or help with packaging Of course, this list is in no way exhaustive or exclusive. Just a first guess. Best Peter

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel October 2021