java-devel

java-devel@lists.fedoraproject.org

1667 discussions

Orphaning ancient java web services packages
by Mat Booth 06 Dec '21

06 Dec '21

I have orphaned wsdl4j, wsil4j and uddi4j. I only needed them for some ancient web services functionality in eclipse-webtools, but obviously eclipse-webtools is no longer in the distro. -- Mat Booth http://fedoraproject.org/get-fedora

3 2

Updated javaparser to 3.22.0 on rawhide
by Markku Korkeala 05 Dec '21

05 Dec '21

Hi, just to notice I updated javaparser to version 3.22.0 in rawhide. What is the best way to see what packages require some package? I tried to see what packages would be affected by the javaparser upgrade with dnf repoquery, but could not get any search results. I tried the following queries: dnf rq --whatdepends mvn$com.github.javaparser:javaparser-parent$ dnf rq --whatdepends mvn$com.github.javaparser:javaparser-core$ dnf rq --whatdepends mvn$com.github.javaparser:javaparser-core$ dnf rq --whatdepends javaparser dnf rq --whatdepends mvn$com.google.code.javaparser:javaparser$ For some other packages I got results. Best regards, Markku

2 2

Corretto?
by Matthew Miller 24 Nov '21

24 Nov '21

I'm curious about this: * https://github.com/amazonlinux/amazon-linux-2022/issues/15 * https://github.com/amazonlinux/amazon-linux-2022/issues/14 ... but have no idea about any of it. :) Anyone have opinions? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

4 4

Need help
by Orion Poplawski 12 Nov '21

12 Nov '21

I'm trying to get truth 1.0.1 to build in the buildroot, but it's having a test failure: [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.01 s <<< FAILURE! - in com.google.common.truth.CorrespondenceExceptionStoreTest [ERROR] com.google.common.truth.CorrespondenceExceptionStoreTest.describeAsMainCause_notEmpty Time elapsed: 0.009 s <<< FAILURE! com.google.common.truth.AssertionErrorWithFacts: expected to match: compare$null, 123$ threw java.lang.NullPointerException\s+at com\.google\.common\.truth\.TestCorrespondences(.|\n)*\n--- but was: compare(null, 123) threw java.lang.NullPointerException: Cannot invoke "java.lang.Integer.intValue()" because "actual" is null at com.google.common.truth.TestCorrespondences$3.apply(TestCorrespondences.java:77) at com.google.common.truth.TestCorrespondences$3.apply(TestCorrespondences.java:74) at com.google.common.truth.Correspondence$FromBinaryPredicate.compare(Correspondence.java:150) at com.google.common.truth.Correspondence$FormattingDiffs.compare(Correspondence.java:389) --- at com.google.common.truth.CorrespondenceExceptionStoreTest.assertExpectedFacts(CorrespondenceExceptionStoreTest.java:106) at com.google.common.truth.CorrespondenceExceptionStoreTest.describeAsMainCause_notEmpty(CorrespondenceExceptionStoreTest.java:64) [ERROR] com.google.common.truth.CorrespondenceExceptionStoreTest.describeAsAdditionalInfo_notEmpty Time elapsed: 0 s <<< FAILURE! com.google.common.truth.AssertionErrorWithFacts: expected to match: compare$null, 123$ threw java.lang.NullPointerException\s+at com\.google\.common\.truth\.TestCorrespondences(.|\n)*\n--- but was: compare(null, 123) threw java.lang.NullPointerException: Cannot invoke "java.lang.Integer.intValue()" because "actual" is null at com.google.common.truth.TestCorrespondences$3.apply(TestCorrespondences.java:77) at com.google.common.truth.TestCorrespondences$3.apply(TestCorrespondences.java:74) at com.google.common.truth.Correspondence$FromBinaryPredicate.compare(Correspondence.java:150) at com.google.common.truth.Correspondence$FormattingDiffs.compare(Correspondence.java:389) --- at com.google.common.truth.CorrespondenceExceptionStoreTest.assertExpectedFacts(CorrespondenceExceptionStoreTest.java:106) at com.google.common.truth.CorrespondenceExceptionStoreTest.describeAsAdditionalInfo_notEmpty(CorrespondenceExceptionStoreTest.java:79) but it builds fine in my rawhide VM. But it's not obvious to me what might be different or what's triggering this. Any help greatly appreciated. -- 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/

3 4

Maven and Ant dependencies ported to Java 17
by Mikolaj Izdebski 03 Nov '21

03 Nov '21

Hello, I've ported all my packages to be buildable with OpenJDK 17. I have not pushed the changes to dist-git yet, but I will do it before the end of the week. I wanted to share common problems I encountered and solutions I came up with. I hope that this will help others trying to port their packages. Problem 1: Compiler source/target levels 1.6 are no longer supported Solution: Bump source/target levels to 1.7 or 1.8 Packages affected: - apache-commons-beanutils - apache-commons-collections - apache-commons-jxpath - apache-commons-logging - apache-commons-net - apiguardian - atinject - bsf - cglib - java_cup - jdom - jdom2 - jsch - junit - jzlib - maven-file-management - maven-plugin-testing - maven-shared-io - munge-maven-plugin - opentest4j - osgi-annotation - plexus-build-api - qdox - sisu-mojos - xalan-j2 - xbean - xml-commons-apis Problem 2: Tests that use reflection fail with <<module java.base does not "opens java.lang">> or similar error Solution: Run tests with appropriate --add-opens parameter passed to JVM Packages affected: - easymock - mockito - xmvn Problem 3: Code does not recognize Java bytecode version 61.0 Solution: Update to newer upstream version that supports newer Java bytecode. Package affected: - objectweb-asm Problem 4: Code is compiled with -Werror passed to javac, but OpenJDK 17 introduces new warnings Solution: Do not pass -Werror to Java compiler Package affected: - jakarta-mail Problem 5: Wildcard imports are used in the code, but OpenJDK 17 introduces new classes that cause import ambiguity Solution: Add explicit imports Package affected: - univocity-parsers Packages that needed changes to make RPM Java packaging tooling to work with OpenJDK 17: - javapackages-bootstrap - javapackages-tools - maven -- Mikolaj

3 5

JDK 17 release package
by Devin Smith 02 Nov '21

02 Nov '21

Would it be possible to create the `java-17-openjdk` and related packages given that JDK 17 is an LTS release? Even though I can "install" against `java-17-openjdk`, I see that it targets the rolling latest release `java-latest-openjdk`.

2 1

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

← Newer
1
2
3
4
5
6
7
...
167
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel