The following metadata was found in MoinMoin that could not be converted to a useful value in MediaWiki:
- : make sure there are no JAR files left
Comments made via fedora-devel-java-list in November 2008
- fix JNI-using JAR files broken link
- remove BR on jpackage-utils
- clarify situation around GCJ
- explain what GCJ does and how this differs from a traditional JVM and how packages can target both simultaneously
- fix templates to have epoch'd BRs/Rs on java and java-devel
- what is "SNPG"?
- answer question at end about preserving line endings
- remove %attr occurrences
- echo "GCJ AOT bits SHOULD be built and included in packages" | 's@in packages@in all Java packages@'
- document what build-classpath does and when to use it
Comments moved from the bottom of the original draft
- Which version of java should stuff be built for? Probably 1.5 (for gcj) if possible? Should mention something about this. (VilleSkyttä)
- I think referencing the GCJ Guidelines, which say the package should build on GCJ, is sufficient, since building on GCJ implies building on 1.5. In general packages should build against/require whatever Java version upstream uses. (ThomasFitzsimmons)
- Referring to GCJ guidelines would work for me, but the 1.5 issue needs to be explicitly mentioned there, it's not clear to everyone. (VilleSkyttä)
- "Requires: java" should have a version in it (depending on which version of java it was built for). Possibly also depend on jre instead of java (maybe this is just cosmetic)? (VilleSkyttä)
- Agreed. I removed the conditional brackets around >= specific_version. I think we should just stick with "java" and not bother with "jre", since that's how it's been done in the past. (ThomasFitzsimmons)
- Thanks. Spec templates still have the unversioned form, though. (VilleSkyttä)
- Drop versioned jars and install only unversioned ones? https://www.redhat.com/archives/fedora-devel-list/2008-March/msg02346.html (VilleSkyttä)
- Fine by me. (ThomasFitzsimmons)
- For users attempting to introduce a new Java package, we should tell them to first check if the package exists on JPackage (JPackage.org). JPackage packages follow a large majority of the guidelines in this draft, and thus importing should be fairly easy. Additionally, having a package in sync with JPackage will prevent potential incompatibility issues with other JPackage packages. (DeepakBhole)
- Would we want that to be a should or a must? In other words, if a packager wants to deviate from the JPackage package but still falls within the Guidelines do we want to allow them that freedom?
- My one major issue with this Guideline is the use of "canonical document" in the header for "Java Packaging". We do have other Guidelines that point to external sources for additional sources but they are targeted pieces (For instance, make sure .desktop files provided by the package follow the freedesktop spec [LINK to spec] ). The Java Guidelines are broader and also have an overlay of information (saying that the JPackage Guidelines are the "canonical document" seems to mean "follow the JPackage Guidelines except where the Fedora Guidelines differ"). This makes it harder for a reviewer to understand what's going on in a package that they attempt to review because they need to keep flipping between two Guidelines and trying to remember where one differs from another. It would be better organization if the Java Guidelines took one of the following approaches: 1) Major concerns listed in the Fedora Guidelines. Specifics point to the relevant section of the JPackage Guidelines. For instance:
=== Jar File Naming === Jar files must be named after the package name using the [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage#id2434750 JPackage Jar File Naming Guideline]
For something that differs we could note the derivation and that our Guidelines take precedence:
=== Jar File Naming === Our rules are derived from the [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage#id2434750 JPackage Guidelines] but we don't use versioned names for jars. Please use the following rules instead: [...]
The alternative to this would be to have people read the entirety of the JPackage Guidelines and then point out the places that we differ. We would probably want to do that by importing the JPackage Guidelines to the wiki and annotating the few cases where we differ. Note that we would probably want to decide whether resyncing when JPackage changes a Guidelines be done automatically or if the new version had to be brought in through FPC -> FESCo approval. We would also need someone from the Java team to do that resyncing as we might otherwise be unaware of the changes.
Item to clarify
(2.8 and 3.2) The Maven specfile template does not include exactly the same text as recommended in the Maven subsection of the Java Packaging section (2). Probably one is an improvement on the other and so one still needs to be improved, but this is all pretty new to me so for now I cannot be specific.
BuildRequires for JNI & Ant
For building a project with Ant that needs javah for generating header you should add the BuildRequires: ant-nodeps. —Preceding unsigned comment added by Fkooman (talk • contribs)
Typo or not?
In the template spec files for ant, shouldn't "Development Documentation" be "Development/Documentation" ? Note that rpmlint considers both of these to be "non-standard" Mycae 09:12, 1 November 2009 (UTC)
Also, the Maven spec file has a typo.
Instead of
%package javadoc
...
Requires: %{name}-%{version}-%{release}
It should be %package javadoc
...
Requires: %{name} = %{version}-%{release}
Admiyo 15:33, 7 April 2010 (UTC)
Draft update
I found the current guidelines to be rather difficult to interpret so I created a suggested updated version: User:Abo/JavaPackagingDraftUpdate