Java Mail extension api
Created attachment 3289 [details] javamail-1.3.ebuild javamail-1.3, installs demos by default with lots of doins lines. Is there a better way to do this?
Created attachment 3290 [details] ChangeLog ChangeLog for 1.3
Created attachment 3291 [details] 21javamail classpath file for javamail
Created attachment 3306 [details] javamail-1.3-r1.ebuild Changed so install env in /usr/share/javamail/package.env
Created attachment 3307 [details] package.env env file to be installed in /usr/share/javamail, this way user can choose classpath with java-config
Created attachment 3310 [details] javamail-1.3.ebuild updated for depend on jaf
Created attachment 3311 [details] javamail-1.3.env renamed env file
Depends on jaf in order to work
I only have bad experience with packaging stuff right off of Sun's web site. They update their upstream packages without prior notice, rename stuff at whim, relicense stuff under more restrictive licenses (ie, jaxp), and are generally not nice to deal with. Are there alternative implementations of this, or is it included in any of the 1.4 (ME, SE, EE) editions of Java ? If so, I'd rather we use that. I'm slowly working on phasing out all stuff provided through Sun's web site, finding workably alternatives instead. When we start marking packages as "stable", none of the packages which download stuff from Sun will ever be marked "stable", as we are not allowed to mirror the tarballs, and thus cannot ensure that it will work for all our users 100% of the time.
I don't believe this or jaf is included in a 1.4 version of java, since they are both optional extensions. I do agree that finding an alternate version of this would be better, so if I do, I'll let you know. This is just what I found since I need it for a project and figured I might as well make an ebuild for it. If you'd rather not add it to portage, that's fine, and I'll see if I can find alternates for both this and jaf.
While we of course appreciate your effort on this, I've had nothing but bad experience with packaging Sun-provided stuff. We're gonna keep the sun-jdk (of course), but I don't want to cram in more Sun-stuff than necessary. As you're the only one who's requested (and even provided a solution to!) this, I don't think it's necessary for our 1.4 release at least, so I'll leave you to finding alternatives. Please reopen the bug when (if?) you figure out some more.
in tree