Bug 543480 - Review Request: javamail - Java Mail API
Summary: Review Request: javamail - Java Mail API
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 540986
TreeView+ depends on / blocked
Reported: 2009-12-02 14:03 UTC by Mary Ellen Foster
Modified: 2010-01-21 00:07 UTC (History)
4 users (show)

Fixed In Version: 1.4.3-2.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-01-21 00:07:53 UTC
orion: fedora-review+
kevin: fedora-cvs+

Attachments (Terms of Use)

Description Mary Ellen Foster 2009-12-02 14:03:13 UTC
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

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.

Comment 1 Joshua Roys 2009-12-14 20:36:09 UTC

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.

Comment 2 Orion Poplawski 2010-01-07 17:31:27 UTC
Good review Joshua, thanks.


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?

Comment 3 Mary Ellen Foster 2010-01-08 11:10:15 UTC
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:

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 ...

Comment 4 Orion Poplawski 2010-01-08 15:22:18 UTC
Thanks for the explanation, no need to go through heroics.


Comment 5 Mary Ellen Foster 2010-01-08 15:56:28 UTC
New Package CVS Request
Package Name: javamail
Short Description: Java Mail API
Owners: mef
Branches: F-11 F-12

Comment 6 Mary Ellen Foster 2010-01-08 15:58:47 UTC
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

Comment 7 Kevin Fenzi 2010-01-09 04:34:50 UTC
cvs done.

Comment 8 Fedora Update System 2010-01-12 23:44:47 UTC
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

Comment 9 Fedora Update System 2010-01-21 00:07:48 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.