Re: [Fwd: Re: [JPackage-discuss] Re: Status of classpathx-mail, classpath-inetlib, gnu-crypto]
Chris Burdess <[email protected]>
| Newsgroups | gmane.comp.java.classpath.extensions.javamail |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Nasser wrote: >>> > One new detail: classpathx-mail cannot be used as a drop-in >>> replacement >>> > for javamail due to its dependency on inetlib. Sorry Ville, I am >>> not sure I understood. Wouldn't it be that as long as someone has >>> the inetlib package then they could install classpathx-mail as a >>> replacement for javamail? >> >> No, merely installing inetlib is not enough (and it's already taken >> care >> of with the rpm dependency). It needs to be included in CLASSPATH one >> way or another too when using classpathx-mail. > > We need to get this solved so we can get javamail (and jaf) on Fedora > as > replacements for the non-open source ones. > > Would it be possible to have a procedure of regularly importing > inetlib sources and changing the packages with a script so we have a > self contained javamail? > > It would still be using inetlib, so not duplicating development. It > would only give us a little bit of work here and there. I believe > that with CVS and vendor branch imports we can actually do this > conversion only once (except for new files). When you say a "self-contained" javamail, you mean packaging all the classes needed at runtime into one JAR file? This would include a JSSE implementation, etc, as specified in the inetlib INSTALL file. It would get messy, especially when people wanted to mix and match with different VMs, library versions, etc. A better solution would be to patch the manifest in the various jar files (gnumail.jar, gnumail-providers.jar, activation.jar, inetlib.jar) - - since the dependency jars have been installed to absolute locations by the package manager, you can simply insert a Class-Path entry in the manifest containing these absolute locations, and Java will locate the dependencies without the user having to specify a classpath explicitly. - -- Chris Burdess -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBG+G+6dl1DEqHgrgRAn5OAKCGUW83iw0ZEz0INTkSS7ECfjp6TACeP4Ux erNMVsy6myfnxXZp6DoEQnk= =f15y -----END PGP SIGNATURE-----