API changes tracker for Java libraries
by Andrey Ponomarenko
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/
8 years
xmvn-install No suitable repository found to store the artifact in
by Enrico Tagliavini
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
8 years, 1 month
What's new in javapackages-tools 4.7.0
by Michal Srb
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
8 years, 1 month
