And why not mount the jvm scheme over the update-alternatives scheme? In my case, I installed maven. Maven searches for /etc/mavenrc and ~/.mavenrc
If I create one of those files, Maven works OK. But as I see it, local configurations are needed if I don't want to use my default configuration, so if I want to use Java SE 6 globally, but J2SE 5 for maven, editing /etc/mavenrc is the way to go. But if I want to use Maven with my default Java installation, I should be able to configure Java in one place, and my specific application (maven in this case) should use my global Java configuration. Currently we have update-java-alternatives as a way to configure the java related commands in only one script, but if I need to configure a java compatible environment I have to edit /etc/jvm or ~/.jvm Maybe if update-java-alternatives could generate (provably based on priority and/or manual mode selection) a base for jvm/java-common to check if no override is created (~/.jvm and /etc/jvm) both worlds could benefit from each other. This could be update-java-alternatives generating a /etc/jvm.default (not much feasible) or java-common returning a default folder maintained by update-java-alternatives if ~/.jvm nor /etc/jvm is found. If I want to customize my default jvm I create a ~/.jvm, but if I happy with the default instalation, everything should work out of the box. -- update-java-alternatives does not change the JAVA_HOME https://launchpad.net/bugs/45348 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
