On Tue, Jan 27, 2015 at 05:31:11PM +0100, Emmanuel Bourg wrote: > Le 27/01/2015 17:11, Jan Niehusmann a écrit : > > > Yes, that would prevent failing builds, as well. But it will also exclude > > gcj architectures, as on these, this dependency is not available. > > Indeed, but gcj doesn't run Java 6 code, so that's normal.
As far as I can tell, it's not really java 6 code, but only some @Override annotations on methods implementing interfaces - which is OK with java 6 but forbidden with java 5. So I _guess_ the byte code would be compatible with java 5. Didn't verify that, though. > I got a quick look at the package, libzmq-java should be 'Architecture: > all' and depend on a 'Architecture: any' libzmq-jni package. Java Policy states: "There may be situations, such as with very small packages, where it is better to bundle the Java code and the native code together into a single package. Such packages should be architecture-specific and follow the usual libXXX[version]-java naming convention." Of course 'very small' is not strictly defined, but I think 35 classes in a 48kB jar file qualifies. It's basically just a wrapper around the native zmq library. > Also the Maven artifacts are missing in /usr/share/maven-repo. That's true, and could be fixed for sure. > Would you want to co-maintain the package with the Java team? We can > help you with these details. Any help is appreciated, so if co-maintainership is the best way to go, I wouldn't mind. Jan -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150127170214.ga29...@jannic.reliablesolutions.de
