Description of problem: some package rely (such as fedora's jetty) rely on the system javamail.jar pointing to the classpathx-mail implementation of javamail. This bug is about using alternative to make jetty use javamail modern implementation Version-Release number of selected component (if applicable): javamail-1.4.3-12.fc18 How reproducible: always Steps to Reproduce: 1. alternative --config javamail Actual results: 1 /usr/share/java/classpathx-mail-1.3.1-monolithic.jar Expected results: 1 /usr/share/java/classpathx-mail-1.3.1-monolithic.jar *+ 2 /usr/share/java/javamail/mail.jar Additional info:
Created attachment 600508 [details] javamail support for alternatives
I am assuming you are talking about Fedora rawhide. > Description of problem: > some package rely (such as fedora's jetty) rely on the system javamail.jar > pointing to the classpathx-mail implementation of javamail. Currently in Fedora rawhide there are no packages that require classpathx-mail directly. Jetty package asks specifically for javamail and not classpathx-javamail. The fact that classpathx-mail is providing /usr/share/java/javamail.jar and virtual package javamail is causing more bad than good. For example "build-classpath javamail" doesn't work as expected. Is there any other reason for providing alternatives for javamail?
(In reply to comment #2) Thx for your answear. > I am assuming you are talking about Fedora rawhide. I'm focusing on f16 (where jetty internally use a symlink to the system alternative) , but anything I can backport will be fine for my own usage. .. > Is there any other reason for providing alternatives for javamail? Packages that would have "Requires: javamail" could still only have a javamail 1.3x implementation. But I guess that if packages would explicitely requires classpathx-javamail that they would rely on the specific classes, such as: gnu.mail.providers.imap.IMAPStore cannot over com.sun.mail.imap.IMAPStore. In that case they should explicitely use classpathx-mail-1.3.1-monolithic.jar instead. On the other side, I think that packages explicitely using a modern javamail would need to have a 'Requires: javamail >= 1.4.x' For Info: # repoquery --whatrequires javamail ant-javamail-0:1.8.2-6.fc16.noarch apache-commons-email-0:1.2-1.fc16.noarch axis-0:1.4-8.fc15.noarch bouncycastle-mail-0:1.46-1.fc16.noarch dumbster-0:1.6-10.fc15.noarch jetty-0:6.1.26-7.fc16.noarch jetty-0:6.1.26-8.fc16.noarch jtnef-0:1.6.0-5.fc15.noarch maven-doxia-0:1.2-2.fc16.noarch mx4j-1:3.0.1-12.fc15.noarch ooo2gd-0:3.0.0-1.fc16.x86_64 tomcat5-0:5.5.31-3.fc15.noarch # repoquery --whatrequires classpathx-javamail
> I'm focusing on f16 (where jetty internally use a symlink to the system > alternative) , but anything I can backport will be fine for my own usage. If you have any particular problem with jetty in F16 using GNU javamail you could just try removing the javamail symlink from /usr/share/jetty/lib/naming and create two new ones pointing to the Oracle implementation (/usr/share/java/javamail/mail.jar and /usr/share/java/javamail/dsn.jar). Also note that jetty in F17 and newer uses Oracle javamail by default. > > Is there any other reason for providing alternatives for javamail? > Packages that would have "Requires: javamail" could still only have a > javamail 1.3x implementation. But I guess that if packages would explicitely > requires classpathx-javamail that they would rely on the specific classes, > such as: > gnu.mail.providers.imap.IMAPStore cannot over com.sun.mail.imap.IMAPStore. > In that case they should explicitely use > classpathx-mail-1.3.1-monolithic.jar instead. The problem is that if a package asks just for javamail, RPM will install the GNU version by default. If your package needs Oracle implementation you could ask specifically for it. > On the other side, I think that packages explicitely using a modern javamail > would need to have a 'Requires: javamail >= 1.4.x' Yes, either this, or something like: Requires: %{_javadir}/javamail/mail.jar > # repoquery --whatrequires classpathx-javamail This should be classpathx-mail Anyways it's unlikely that this will be fixed in Fedora 16 because only major bug fixes and security fixes are supposed to be added to old releases. In F18+ I think it would be better to remove classpathx-mail completely and in this case there would be no need for alternative.
Indeed we are deprecating classpathx-mail in F18+ so this is no longer going to be an issue. We'll keep this bug updated
classpath-mailx was removed from Fedora Rawhide, which should fix your problem. The update is impossible for Fedora 16 or 17.
Thx, but the packages using javamail from %{_javadir}/javamail.jar instead of %{_javadir}/javamail/mail.jar still need to be corrected to use the new path. Using alternatives would help to reduce the changes from the dependent packages and also to use the expected namespace: %{_javadir}/javamail.jar. Alternatives would also permit to maintain an EPEL6 version. (BTW, there is an update for javamail to 1.4.5.)
> Thx, but the packages using javamail from %{_javadir}/javamail.jar instead > of %{_javadir}/javamail/mail.jar still need to be corrected to use the new > path. That's true, and I am aware of that. I have already informed maintainers of dependent packages that the need to rebuild their packages against javamail. I'm quoting the email I sent: > Hi all, > > classpathx-mail has recently been deprecated. Please build your packages > against javamail package, which should be compatible with classpathx-mail. > > classpathx-mail used to have javamail virtual provide, so unless your > packages referenced classpathx-mail directly there should be no need > to change them (but in this case release tag bump and rebuild may still > be needed). > > The following packages were using classpathx-mail: > * ant, > * apache-commons-email, > * apache-commons-vfs, > * axis, > * axis2, > * bouncycastle-mail, > * cxf, > * dumbster, > * ironjacamar, > * jboss-as, > * jtnef, > * maven-doxia, > * mx4j, > * ooo2gd, > * ovirt-engine, > * quartz, > * resteasy. > > Thanks, > Mikolaj Izdebski That's all I can do. If that packages aren't rebuilt then feel free to file bug reports against them. > Using alternatives would help to reduce the changes from the dependent > packages and also to use the expected namespace: %{_javadir}/javamail.jar. It's not that simple. As far as I remember javamail has different jar structure than GNU mail (multiple jars instead of one). But dependant packages shouldn't need any changes to start using javamail, maintainers just need to rebuild them. > Alternatives would also permit to maintain an EPEL6 version. If there is someone that wants to maintain we can reconsider the solution with alternatives.
I've tried to look at EPEL6 but the miss of maven build dependency is a problem to maintain a package there. So I expect it to be fixed in "Future EL" Now I really like to push the alternatives support anyway, since it will help to have compatibility with older implementation, and probably help to "port" and test application compatibility with future EL. For the time been I've made a scratch build targeting f16 with the hope that it can work on el6 and do runtime tests.
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4428795