I believe emerge --info should include the default java vm for both java-config-1 and java-config-2, it would help when people submit bugs relating to java compile issues. In a recent case with glib-java, it was producing an error b/c the java-config-1 vm was set to the jre for some reason. see bug #139480
@Java Team: I'll leave this up to you. If it's only an env var just add it in profiles/info_vars in the tree, but if it requires something more complicated we'll have to talk about it.
After working on some solutions to have emerge spit out it, I that emerge --info --verbose list some of the java var's, one being VMHANDLE. Instead of listing this in --verbose, should it be listed in just the regular --info.
There are a few variables that I can think of that would be useful. Aside from that, it would be nice to have what versions of java-config and java-config-wrapper are installed.
OK, so I realized I could just add dev-java/config to info_pkgs. Is that fine to just do? As for VMHANDLE, I think I'd rather do that in a die hook in java-pkg.eclass. We already do give a lot of info in java-utils-2.eclass's die hook. The only other thing that may be useful would be reporting the build-vm configuration, ie /etc/java-config-2/build/jdk.conf, as well as compiler configuration, ie /etc/java-config-2/build/compiler.conf.
I've added java-config to info_pkgs. That should be enough for now.
(In reply to comment #4) > The only other thing that may be useful would be reporting the build-vm > configuration, ie /etc/java-config-2/build/jdk.conf, as well as compiler > configuration, ie /etc/java-config-2/build/compiler.conf. One way to go about this might be to add a --info hook that runs a shell script from the portage tree. It would be similar to info_vars and info_pkgs, but you'd have the ability to run arbitrary shell commands.
Or maybe go the perl route and provide a separate tool for domain specific use cases. The general `emerge --info` should really be limited to a minimum to prevent information overload.
