The huge deptree of dev-java/mx4j

MX4J is an open source implementation of the JMX and JMX Remote API (JSR 160) specifications. The alternatives for mx4j are sun-jmx, which is fetch restricted, and 1.5 jdks where jmx is integrated into the JDK. Because of the fetch restriction a decision was made a while ago to use the OSS implementation. Because of the mx4j-tools that came with the dev-java/mx4j package the deptree was quite huge. For this reason wltjr added the java5 use flag to Tomcat. This use flag avoided depending on stuff that is provided by 1.5 jdks any way. Last Thursday this problem was solved for good by using the solution from Now the latest ~x86 versions of dev-java/commons-modeler and www-servers/tomcat depend on the new dev-java/mx4j-core that has very minimal dependencies. If you are using ~arch, upgrading to these versions might help you clean some java packages with emerge -a –depclean.

Some of you have contacted me about my Avatar and not liking the military look of it. Well probably it is not such of a common sight in other countries but bear with me, I only have 27 mornings left.

Splitting ant

So soon ant-1.7.0 should be hitting the stable Gentoo machines. The biggest benefit here is that full ant with it’s big dependency tree shouldn’t be pulled in so often any more. Not all of the packages are migrated to splitted ant yet but the most important ones like Tomcat are. If you are interested in how this works I recommend you to take a look at the Ant guide we wrote:

Changes in Java overlays

If you use the java overlays see the following link:

The changes should allow a better experience to users of our overlays as we now have one central overlay where things are expected to work for layman usage and after we get it cleaned there shouldn’t be any experimental work in there. Initially I just moved migrated-java-experimental-overlay as java-overlay so initially there is still some experimental stuff left in that overlay but they should not have any keywords. If you have any problems, use our mailing list or IRC channel to get help.

Most of Sun’s Java class library under GPL now

betelgeuse@pena ~/openjdk/control/build/linux-i586 $ ./bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-betelgeuse_08_may_2007_21_32-b00)
OpenJDK Tiered VM (build 1.7.0-internal-betelgeuse_08_may_2007_21_32-b00, mixed mode)

Stay tuned for more packaging updates on Gentoo.

OpenJDK ebuild

betelgeuse@pena ~ $ eselect java-vm list
Available Java Virtual Machines:
  [1]   blackdown-jdk-1.4.2
  [2]   ibm-jdk-bin-1.5
  [3]   kaffe
  [4]   openjdk-1.7  user-vm
  [5]   sun-jdk-1.4
  [6]   sun-jdk-1.5
  [7]   sun-jdk-1.6  system-vm
  [8]   sun-jdk-
  [9]   sun-jdk-1.7

Takes me about 45 minutes to build on:

betelgeuse@pena ~ $ uname -p
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz

Please note the word experimental in the url. Now I am off to bed for today. Have an exam in C programming coming up tomorrow.

Updating Bluetooth packages

For quite a while now the bluez packages on Gentoo haven’t been maintained so we have been stuck in 2.25. I decided to fix this so I bumped bluez-libs and bluez-utils to 3.10. You need to run revdep-rebuild –library as upstream decided to increase the .so number to 2. Also worth nothing is that they have changed the way pins are asked from the user to a DBUS based API. If you have security set to user in hcid.conf you most likely want to install an applet that asks the PIN from you. There is now net-wireless/bluez-gnome for GNOME users and >=net-wireless/kdebluetooth-1.0_beta2 for KDE users.
The bug reports this fixed are
bluez-libs and bluez-utils:
A couple of new ones were opened against the new version too so there is still some work before it is ready for stable. Hopefully I just need to proxy maintain the packages for a user.