Spec URL: http://www.macs.hw.ac.uk/~mef3/soprano-sesame/javamail.spec SRPM URL: http://www.macs.hw.ac.uk/~mef3/soprano-sesame/javamail-1.4.3-1.fc12.src.rpm Description: The JavaMail API provides a platform-independent and protocol-independent framework to build mail and messaging applications. Note: This is the successor to the glassfish-javamail packages -- see http://java.sun.com/products/javamail/. The classes included in the smtp, pop3, imap, and mailapi sub-packages are all also in the main javamail.jar.
Hello, Here's an unofficial review: * rpmlint (the warning is in error; the _libdir macro is used inside the same conditional that triggers the package being noarch) $ rpmlint -vi /var/lib/mock/fedora-12-x86_64/result/javamail-*.rpm javamail.src: I: checking javamail.src:207: W: libdir-macro-in-noarch-package (main package) %attr(-,root,root) %{_libdir}/gcj/%{name} The %{_libdir} or %{_lib} macro was found in a noarch package in a section that gets included in binary packages. This is most likely an error because these macros are expanded on the build host and their values vary between architectures, probably resulting in a package that does not work properly on all architectures at runtime. Investigate whether the package is really architecture independent or if some other dir/macro should be instead. javamail.x86_64: I: checking javamail-debuginfo.x86_64: I: checking javamail-javadoc.noarch: I: checking 4 packages and 0 specfiles checked; 0 errors, 1 warnings. * package is named appropriately * spec is %{name}.spec * spec file in general is ok; minor nitpick: -- comment on line 112, convert license file to....? * approved license * license matches mail/src/main/resources/META-INF/LICENSE.txt * license included as %doc * specfile written in American English * ... and is legible * files match upstream (checked via `spectool -g' and `diff') * builds via mock on x86_64 ? ExcludeArch? do a scratch build in koji to check compile on all archs? * builds in mock: BuildRequires are probably correct ~ n/a locales ~ n/a ldconfig * does not bundle copies of system libraries ~ n/a not relocatable * handles directory ownership/creation correctly * %files doesn't duplicate anything * %defattr provided, proper permissions * %clean is correct * consistent macro usage * package contains code * no overly large docs * the only %doc files are a license and a html page ~ n/a no headers ~ n/a no static libraries ~ n/a no pkgconfig files * no foo.so.#.# files, only foo.so ~ n/a no -devel subpackage * no .la files * no gui app (that I'm aware of?) * no duplicate directory ownership * %install has a rm -rf $RPM_BUILD_ROOT * all filenames are valid UTF-8 Hope to help.
Good review Joshua, thanks. Other: BR/R - tomcat5-jsp-2.0-api and maven2 will bring in tomcat5-servlet-2.4-api, so not strictly needed. Are we causing ourselves trouble by renaming mail.jar -> javamail.jar and dsn.jar -> javamail-dsn.jar? Perhaps just putting them into /usr/share/java/javamail/ ? Is it possible anymore to split out the various sub-packages?
The problem with the sub-packages is: the parent pom.xml does some sort of maven magic with the "bundle" plugin that's beyond me, and that seems to make use of the maven osgiversion plugin which isn't yet available on Fedora. The intended build sequence appears to be: compile everything and bundle it into mail.jar, and then also extract classes from that into sub-packages (e.g., com.sun.mail.imap.* into imap.jar). I asked about this on the upstream forum and that's what the developer said: http://kenai.com/projects/javamail/forums/forum/topics/2084-Where-is-the-source-for-imap-pop3-smtp-mailapi- However, when I remove all of the unavailable plugins and try to build the sub-packages, every sub-jar just ends up containing all of the classes from mail.jar all over again. The "dsn" sub-package is fine because its source files are actually included separately, unlike the other ones. I could just manually build the other jar files by running "jar" myself, I guess ...
Thanks for the explanation, no need to go through heroics. Approved.
New Package CVS Request ======================= Package Name: javamail Short Description: Java Mail API Owners: mef Branches: F-11 F-12
For posterity, I'll note that I've made a couple of small changes to the original package based on the review comments: - Removed the unnecessary (build)requirement for tomcat-servlet-2.4-api - Put the jar files into a "javamail" subdirectory Spec URL: http://www.macs.hw.ac.uk/~mef3/soprano-sesame/javamail.spec SRPM URL: http://www.macs.hw.ac.uk/~mef3/soprano-sesame/javamail-1.4.3-2.fc12.src.rpm
cvs done.
javamail-1.4.3-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update javamail'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0481
javamail-1.4.3-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.