I have several doubts/suggestions:
1. What a Java package is? There are a lot uses of this term, but I couldn't find the definition.
2. "If the package provides a single JAR and the filename provided by the build is neither %{name}-%{version}.jar nor %{name}.jar then this file MUST be installed as %{name}.jar and a symbolic link with the usual name must be provided." What if the usual name is already taken by another package? Sholdn't the working be "should be provided"?
3. "You can use either package names (all jar files will be included) or jar filenames with path prefix to select only some jar files from whole package." So if package FOO provides 2 jars: FOO.jar and BAR.jar, build-classpath FOO1 will give both jars, but build-classpath ./FOO` only the first?
4. "For older releases and EPEL, refer to the maven 2 template." Could you provide a link?
5. "Add symbolic link %{_javadir}/javax.XXX.jar that will point to the implementation" What is "the implementation"? Jar files with classes? If yes then how can you create 1 symlink to multiple files?
6. "You can use either package names (all jar files will be included)" All jars? Even those in /lib?
7. Sometimes you write JAR, sometimes jar and sometimes Jar. Is it intentional?
I have the following observations/suggestions related to the JNI section:
1. Perhaps it should be re-stated in this section that the BuildRequires and Requires for java packages as documented in "https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#BuildRequires_and_Requires" also apply to all JNI packages (i. e. - all JNI packages must specify both 'java-devel' and 'jpackage-utils' for BuildRequires and both 'java' and 'jpackage-utils' for Requires).
2. I would like to suggest adding the following example to the "https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#Guideline" section:
-
To satisfy this Fedora requirement of using "System.load()" instead of "System.loadLibrary()" while still providing 32-bit versus 64-bit usability as well as complying with Java's write-once-run-anywhere goal, each JNI jar file should contain code similar to the following (as used in the pki-symkey JNI package):
static boolean tryLoad(String filename) {
try {
System.load(filename);
} catch (Exception e) {
return false;
} catch (UnsatisfiedLinkError e) {
return false;
}
return true;
}
// Load native library
static {
boolean mNativeLibrariesLoaded = false;
String os = System.getProperty("os.name");
if ((os.equals("Linux"))) {
// Check for 64-bit library availability
// prior to 32-bit library availability.
mNativeLibrariesLoaded =
tryLoad("/usr/lib64/symkey/libsymkey.so");
if (mNativeLibrariesLoaded) {
System.out.println("64-bit symkey library loaded");
} else {
// REMINDER: May be trying to run a 32-bit app
// on 64-bit platform.
mNativeLibrariesLoaded =
tryLoad("/usr/lib/symkey/libsymkey.so");
if (mNativeLibrariesLoaded) {
System.out.println("32-bit symkey library loaded");
} else {
System.out.println("FAILED loading symkey library!");
System.exit(-1);
}
}
} else {
try {
System.loadLibrary("symkey");
System.out.println("symkey library loaded");
mNativeLibrariesLoaded = true;
} catch (Throwable t) {
// This is bad news, the program is doomed at this point
t.printStackTrace();
}
}
}
3. Bugzilla Bug #847130 - noarch packages may depend on arch-independent bytecode in %{_libdir}/eclipse specifies that "...in rawhide (and now in f18), noarch packages can't resolve %{_libdir}", but Java noarch packages (i. e. - tomcatjss) that depend upon the value of '%{_jnidir}' currently break in rawhide because they are unable to locate their required JNI jar (i. e. - '/usr/lib/jss4.jar' vs. '/usr/lib64/jss4.jar'). Hopefully this problem will be resolved once the appropriate 'jpackage-util' packages (which re-define the '%{_jnidir}' macro to '%{_prefix}/lib/java') are present in rawhide, and JNI packages can be rebuilt such that they always place their jar files under this re-defined '%{_jnidir}', and thus noarch packages can still rely upon the use of the '%{_jnidir}' macro?