java-devel March 2016

java-devel@lists.fedoraproject.org

8 participants
4 discussions

API changes tracker for Java libraries
by Andrey Ponomarenko 09 Apr '16

09 Apr '16

Hello, I've just opened the new API changes tracker for Java libraries: http://abi-laboratory.pro/java/tracker/ As the first step I've prepared reports for a random set of libraries: Android, Berkeley DB JE, Commons Collections, Hadoop, log4j and SLF4J. The reports are generated by the new 1.5 version of the japi-compliance-checker tool. It's a big and useful update and it's highly recommended to update the tool if you are using it in your project: https://github.com/lvc/japi-compliance-checker I'd like to ask the community what libraries would you like to see in the tracker? Thanks for your feedback. BTW: The old tracker reports are still hosted by the ROSA Linux team but not updated anymore: http://upstream.rosalinux.ru/java/

3 9

xmvn-install No suitable repository found to store the artifact in
by Enrico Tagliavini 21 Mar '16

21 Mar '16

Hi there, I'm trying to make an RPM package for junixsocket [1] but am hitting a wall with xmvn-install (build log trimmed for brevity): [INFO] ----------------------------------------------- [INFO] TARGET ARTIFACT: [INFO] groupId: JPP/junixsocket [INFO] artifactId: junixsocket-native-common [INFO] extension: jar [INFO] classifier: [INFO] version: SYSTEM [INFO] stereotype: native [INFO] namespace: [INFO] file: usr/lib/java/junixsocket/junixsocket-native-common.jar [INFO] =============================================== [WARNING] Failed to resolve artifact: com.kohlschutter.junixsocket:junixsocket-native:nar:2.0.4 [WARNING] Unable to resolve dependency artifact com.kohlschutter.junixsocket:junixsocket-native:nar:2.0.4, generating dependencies with unknown version and n amespace. [WARNING] Failed to resolve artifact: com.kohlschutter.junixsocket:junixsocket-native:nar:amd64-Linux-gpp-jni:2.0.4 [WARNING] Unable to resolve dependency artifact com.kohlschutter.junixsocket:junixsocket-native:nar:amd64-Linux-gpp-jni:2.0.4, generating dependencies with u nknown version and namespace. + jdir=target/site/apidocs + '[' -d target/site/apidocs ']' [DEBUG] Effective packaging rule for com.kohlschutter.junixsocket:junixsocket-native:nar:2.0.4: <?xml version="1.0" encoding="UTF-8"?> <configuration xmlns="http://fedorahosted.org/xmvn/CONFIG/1.0.0"> <artifactManagement> <rule> <artifactGlob> <groupId>com.kohlschutter.junixsocket</groupId> <artifactId>junixsocket-native</artifactId> <version>2.0.4</version> <extension>nar</extension> </artifactGlob> <optional>false</optional> </rule> </artifactManagement> </configuration> [WARNING] Skipping installation of artifact com.kohlschutter.junixsocket:junixsocket-native:nar:2.0.4: No suitable repository found to store the artifact in. [DEBUG] Effective packaging rule for com.kohlschutter.junixsocket:junixsocket-native:nar:amd64-Linux-gpp-jni:2.0.4: <?xml version="1.0" encoding="UTF-8"?> <configuration xmlns="http://fedorahosted.org/xmvn/CONFIG/1.0.0"> <artifactManagement> <rule> <artifactGlob> <groupId>com.kohlschutter.junixsocket</groupId> <artifactId>junixsocket-native</artifactId> <version>2.0.4</version> <classifier>amd64-Linux-gpp-jni</classifier> <stereotype>native</stereotype> <extension>nar</extension> </artifactGlob> <targetPackage>__noinstall</targetPackage> <optional>false</optional> </rule> </artifactManagement> </configuration> As far as I understand this is not a bug [2] because nar is not a standard artifact. How do I tell xmvn how to do that? I tried adding <?xml version="1.0" encoding="US-ASCII"?> <configuration xmlns="http://fedorahosted.org/xmvn/CONFIG/2.0.0"> <repositories> <repository> <id>install-nar</id> <type>SimpleRepository</type> <stereotypes> <stereotype> <type>native</type> <extension>nar</extension> <classifier/> </stereotype> </stereotypes> <configuration> <repositories/> </configuration> </repository> </repositories> </configuration> to the configuration, but it didn't solved the issue. Honestly I'm just wild guessing here, I can't find any example to follow. I'm also ok to install it manually, but have no clue how to do that either. I can copy the archives (not only the nar, also the corresponding jar is skipped, since it depends on the nar I guess) into the %{buildroot}, but what about the pom files? Also note I'm using trying to do this on CentOS 7, not Fedora, so quite an older version of xmvn (1.3.0). Thank you for the help. Best regards Enrico Tagliavini [1] https://github.com/kohlschutter/junixsocket [2] https://bugzilla.redhat.com/show_bug.cgi?id=1034732

3 3

What's new in javapackages-tools 4.7.0
by Michal Srb 06 Mar '16

06 Mar '16

Hi everybody, I am pleased to announce release of javapackages-tools 4.7.0. Changelog: * new RPM macro %gradle_build for building Gradle projects (already backported to F24/Rawhide for quite some time) * see `gradle_build` man page for more information, or consult with documentation [1] * RPM dependency generators now automatically emit Requires on javapackages-tools instead of jpackage-utils * see rhbz#1237344 * long-time deprecated RPM macros %_mavendepmapfragdir and % _mavendepmapdir have been removed * javapackages-tools package no longer owns unused %{_datadir}/maven-effective-poms directory * moved mvn_build and builddep from maven-local to javapackages-local subpackage * see rhbz#1290399, already backported to F24/Rawhide for quite some time * updated documentation * see rhbz#1247385 Version 4.7.0 is available in Fedora Rawhide now. Enjoy. Michal [1]: https://fedorahosted.org/released/javapackages/doc/#gradle

1 0

Unresponsive maintainer: lgao
by gil 04 Mar '16

04 Mar '16

Hi Is already for some time (a few months) that I have no news, I did request to become co maintainer for this package https://admin.fedoraproject.org/pkgdb/package/rpms/shrinkwrap-descriptors/ This package suffer of F24FTBFS, i submitted patch for solve the issues: shrinkwrap-descriptors: https://bugzilla.redhat.com/show_bug.cgi?id=1308127 <https://bugzilla.redhat.com/show_bug.cgi?id=1239576><https://admin.fedoraproject.org/pkgdb/package/snappy-java/> But until now I have not had any response from the maintainer, lgao (Lin Gao lgao(a)redhat.com) . Someone could take steps to apply the proposed adjustments? Thanks in advance gil

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel March 2016