Bugzilla Bug 152924

dev-java/mx4j:tools - Build optional tool classes and utilities

Created an attachment (id=100555) [edit]
mx4j-2.1.0-r1.diff

(From update of attachment 100555 [edit])
After some discussion it was agreed the new USE flag approach is inadequate for
a number of reasons, most of all because jetty depends on mx4j, and mx4j's
optional tools depend on jetty.

The new idea is to split mx4j into two ebuilds: core (dev-java/mx4j) and tools
(dev-java/mx4j-tools). The core ebuild will no longer depend on jetty, and the
jetty dependency will be moved to mx4j-tools. As a consequence of this
splitting, the mx4j Ant build is now patched to split the javadoc target into
two targets corresponding to core and tools, and also mx4j's "examples" USE
flag has been moved over to the mx4j-tools ebuild due to the infeasability of
splitting it.

Created an attachment (id=100624) [edit]
mx4j-2.1.0-r2.ebuild

Created an attachment (id=100625) [edit]
files/mx4j-2.1.0-split-javadoc-build.patch

Created an attachment (id=100626) [edit]
mx4j-tools-2.1.0.ebuild

Created an attachment (id=100627) [edit]
files/mx4j-tools-2.1.0-split-javadoc-build.patch

Created an attachment (id=100633) [edit]
mx4j-2.1.0-r2.ebuild

Update to more explicitly define a few of the build-time jar imports.

Tested on x86 against sun-jdk-1.4.2.12 using javac 1.4.2.12, jikes 1.22, and
ecj 3.2.

Created an attachment (id=100634) [edit]
mx4j-tools-2.1.0.ebuild

Update to more explicitly define a few of the build-time jar imports.

Tested on x86 against sun-jdk-1.4.2.12 using javac 1.4.2.12, jikes 1.22, and
ecj 3.2.

Created an attachment (id=100635) [edit]
mx4j-3.0.1-r2.ebuild

Now for slot 3.0.

Tested on x86 against sun-jdk-1.4.2.12 using javac 1.4.2.12, jikes 1.22, and
ecj 3.2. Also tested on x86 against sun-jdk-1.5.0.08 using javac 1.5.0.08,
jikes 1.22, and ecj 3.2.

Compilation against jdk-1.3 in mx4j-3.0.1-r1 from Portage was broken due to
incomplete implementation of build steps, so this revision of the ebuild
requires >=virtual/jdk-1.4. See comments in ebuild.

Created an attachment (id=100636) [edit]
files/mx4j-3.0.1-split-javadoc-build.patch

Created an attachment (id=100637) [edit]
mx4j-tools-3.0.1.ebuild

Tested on x86 against sun-jdk-1.4.2.12 using javac 1.4.2.12, jikes 1.22, and
ecj 3.2. Also tested on x86 against sun-jdk-1.5.0.08 using javac 1.5.0.08,
jikes 1.22, and ecj 3.2.

Created an attachment (id=100638) [edit]
files/mx4j-tools-3.0.1-split-javadoc-build.patch

I've already bugspammed enough for today, so I'll just mention here that
mx4j-2.1.0-r2.ebuild and mx4j-3.0.1-r2.ebuild need to have an einfo added to
pkg_postinst() saying:

"Tools and examples are now located in a separate package,
dev-java/mx4j-tools."

It would be nice if we could get this upstream too so that we would not end up
maintaining the patches ourselves.

    [javac] 7. ERROR in
/var/tmp/portage/dev-java/mx4j-tools-3.0.1/work/mx4j-3.0.1/src/tools/mx4j/tools/adaptor/ssl/SSLAdaptorServerSocketFactory.java
    [javac]  (at line 24)
    [javac]     import com.sun.net.ssl.KeyManagerFactory;
    [javac]            ^^^^^^^^^^^
    [javac] The import com.sun.net cannot be resolved

Stupid tools don't compile with ibm-jdk-bin

https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java
Added with the following modifications:
- mx4j core code is now in the mx4j-core package
- mx4j package depends on both -core and -tools and has examples and doc use
flags
- This way emerge mx4j will give you about the same result as the upstream
binary
- the mx4j metapackage needs a patched java-pkg-opt-2 eclass so that it does
not     
  do build.xml rewriting when no java code is used but I will commit that soon

(From update of attachment 100637 [edit])
Use version in Java overlay.

(From update of attachment 100635 [edit])
Use version in Java overlay.

I started to think that having mx4j with the tools use flag would have been
easier to implement. But just now I came to think that as mx4j-tools can depend
on jetty and jetty depends on mx4j-core, it is wiser to go with three ebuilds
as then we can avoid the circular deps altogether.

Split ebuilds committed to the tree. Thanks shillelagh.