Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 360255 - New ebuild to replace dev-java/jsr67-1.3
Summary: New ebuild to replace dev-java/jsr67-1.3
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Java (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Java team
Keywords: EBUILD, Inclusion
Depends on:
Reported: 2011-03-24 11:04 UTC by Nico R.
Modified: 2012-08-12 12:30 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

ebuild for building jsr67-1.3 from source (jsr67-1.3-r1.ebuild,850 bytes, text/plain)
2011-03-24 11:04 UTC, Nico R.

Note You need to log in before you can comment on or make changes to this bug.
Description Nico R. 2011-03-24 11:04:30 UTC
Created attachment 267067 [details]
ebuild for building jsr67-1.3 from source

For quite a long time, I have been unable to build or use NetBeans due to strange licensing issues. dev-java/jsr67 was one of the packages preventing me from using NetBeans.

I am attaching a new ebuild for dev-java/jsr67, which actually builds the package from a source package. The source JAR comes from the SVN repository of the SAAJ project at It was the best version I could find that is similar to the binary JAR (containing compiled class files) used by the current jsr67-1.3.ebuild (I got that binary JAR from the Gentoo mirrors, because the site has been restructured). If someone finds an even better source JAR to use, go ahead.

This should fix my problems with licenses. However, it is possible that dev-java/netbeans(-1.9.1) should depend on java-virtuals/saaj-api instead of dev-java/jsr67, not sure.

I have not tested whether the functionality provided by the new classes compiled by this new ebuild is actually equal to the classes before, because I do not know how to do that properly. I figured that the best way to do it might be to compare the API (public classes, methods, fields etc.) provided by both JARs.
Comment 1 Petteri Räty (RETIRED) gentoo-dev 2011-03-24 21:05:27 UTC
You can use dev-java/japitools to compare jars. Here's our own wrapper script for it:
Comment 2 Nico R. 2011-03-28 12:18:08 UTC
Thanks for the pointer. I had to hack the apicheck script a bit, and had to remove some classes from rt.jar for the comparison, but it worked fine. APIs are identical (according to the script output).

However, /usr/lib/icedtea6/jre/lib/rt.jar from dev-java/icedtea-6.1.10 installed from the java-overlay already includes javax/xml/soap/*.class. It seems that jsr67 is not needed if IcedTea is installed. I don’t know about other JREs. It is possible that NetBeans wants the classes in a separate JAR, though, for its module system. Perhaps someone who knows the details better can have a look at this? Thanks.

For now, it seems that the old jsr67 ebuild can be replaced with my version without problems. Please add the new ebuild file to the portage tree so that we a free NetBeans can be built and used. Thanks.
Comment 3 Serkan Kaba (RETIRED) gentoo-dev 2011-03-28 15:23:59 UTC
(In reply to comment #2)
We already handle its jdk inclusion with saaj-api virtuals (although some packages are still depending on jsr67) but Netbeans expects concrete jars and we can't do anything about that.
Comment 4 Nico R. 2012-08-12 12:30:48 UTC
(In reply to comment #3)
> (In reply to comment #2)
> We already handle its jdk inclusion with saaj-api virtuals (although some
> packages are still depending on jsr67) but Netbeans expects concrete jars
> and we can't do anything about that.

Yeah, that’s a different problem. My main problem with dev-java/jsr67 is its license.

If we can’t get rid of the jsr67 JAR, because NetBeans wants JARs, then we can at least replace the jsr67 JAR (copied binary, Sun restrictive license) with a functionally equivalent one built from sources and with a free license.

If we still want to keep jsr67 in its current form, wrap it in, let’s say, java-virtuals/saaj-api-jar, and have the latter RDEPEND on
  "|| (
. dev-java/saaj-api-jar would be a new ebuild without the non-free license.

For jsr67 (or saaj-api-jar), I see two possibilities:
1) generate it from sources (see attached ebuild),
2) extract class files from rt.jar of an installed JDK. Should be at least possible with IcedTea 1.6 or 1.7, don’t know for other implementations of virtual/jdk.

In my opinion, a use flag like ‘extract-classes’ or ‘rebuild-classes’ or similar could be used to differentiate between the two.

I reckon that it might be necessary to also add a manifest to the built/constructed JAR, which includes the following lines, in case NetBeans or one of the other ebuilds depending on dev-java/jsr67 reads the Specification data:
  Manifest-Version: 1.0
  Specification-Title: SAAJ
  Specification-Version: 1.3

Solution 2) would do something like:
    jar -xf "${JAVA_HOME}/jre/lib/rt.jar" javax/xml/soap/
    jar -cfm jsr67.jar manifest javax

"${JAVA_HOME}" must probably be replaced by a more clever piece of code; I don’t know the java eclasses too well.

Ebuilds using dev-java/jsr67 are (only includes latest revisions):

All except the NetBeans ebuild use java-pkg_jar-from. As far as I can tell, they will not run into problems if jsr67 is replaced (or replaced by a virtual).