Re: [gentoo-java] Java 1.5 migration plans

[Martin von Gagern <Martin.vGagern@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 5334 bytes --]

Hi There!

I'm neither dev, nor did I have the time to look at all the affected
sources, so please be indulgent when I write nonsense.

After some late night IRC chat with axxo, I have another plan to
propose. I hope it might provide a way to smoothly change over, without
having to break major functionality in between, and with the possibility
to test things on ~arch first and to have changes on a per ebuild basis.


Phase 1)

The basic idea is to install wrappers in /usr/lib/java-wrappers or
something like that for some time. So no current ebuilds would break.

The location of java is determined by
1. PATH,
2. JAVA_HOME,
3. java-config output or
4. well known location (/usr/bin/).

1. and 2. are environment settings and can be modified by an eclass
(java-migrate.eclass?) so that new ebuilds could start using the new
run-java-tool wrappers.
For 3., those packages could depend on the new java-config.
4. is a problem in any case, so that new ebuilds can be expected to have
this solved or they won't work in any scenario.

I give some details on the compatibility of java-config below.
The idea is to have java-config handle new style symlinks and old style
env setting files at the same time with almost no work to be done.


Phase 2)

Now the wrappers are available, and ebuilds can at merge time switch to
using them instead of the old style VM settings. New ebuilds would use
an eclass to set the environment accordingly and to DEPEND on a recent
java-config. This could be done on a per ebuild basis, first for ~arch
and then for arch.

Packages that need it could DEPEND on javatoolkit as well.
New eclasses can be provided as long as they set correct DEPENDencies.


Phase 3)

All "complicated" ebuilds should be moved to using the new system. Those
are the ones that don't simply call ant but do some more elaborate
stuff. By a new version of java-config, the 20java file could be changed
again to make /usr/lib/java-wrappers the JAVA_HOME. Details for this are
below again. ant should continue to work, so still nothing breaks.
Now the new style is the default, and the old style is adapted to use
the new wrappers.

Phase 4)

java 1.5 can be unmasked for ~arch. Things that still don't work will be
noticed and can be fixed by using the merge time features of the new
system without much trouble.

Phase 5)

All ebuilds should be changed to using the wrappers and stabilized.
Now the wrappers could be symlinked, copied or moved to /usr/bin, the
env setting file 20java could be enoticed for removal.



Details on compatibility of java-config and run-java-tool:

Using the run-java-tool wrappers with java-config would require a recent
version of java-config. I suggest the java-config ebuild makes
/etc/env.d/20java a symlink to /etc/java-config/system-vm/env-settings
or some such, and every jdk and jde contains this settings file (which
is just a copy / symlink to the file listed in /etc/env.d/java if I got
this right). This can be done with the revision bumps that are needed
anyway.

So as the new java-config changes the system-vm symlink, automatically
the contents of 20java changes, and the usual procedure of env-update
and source profile makes this configuration change active, as it was
with java-config so far. The new java-config would without much
additional work reproduce the workings of the old one, in addition to
changing the symlinks in the new style.

The 20java file as it was when installing could be moved to some new dir
(e.g. /etc/java-config/old-vm), and the java tools identified by the
java file could be symlinked to this directory as well, so that this
directory can be used as a new style java vm installation exactly
representing the settings in effect when the java-config ebuild is
installed. When java-config is called to switch vm, the system-vm
symlink changes and the directory just described may be safely removed.

So to sum it up, here is how java-config installation should work:
1. mkdir -p /etc/java-config/old-vm/bin
2. mv /etc/env.d/20java /etc/java-config/old-vm/env-settings
3. ln -s ../java-config/system-vm/env-settings /etc/env.d/20java
4. ln -s old-vm /etc/java-config/system-vm
5. ln -s `java-config -c` /usr/java-config/old-vm/bin
   same for all the other java tools

3. makes sure that vm changes with the new java-config also change the
   environment settings the way the old config did.
2. makes the current settings available for old style env-update.
5. makes the currently selected vm available for the new style wrappers,
   it would have to use the old java-config.
4. sets this constructed configuration as current vm in the new style.

The user would need new VM packages with new environment setting files
only for switching VM, the current setting would continue to work under
the new java-config even without this update.



Details about the flow of indirection in Phase 3)

Before Phase 3 we had for old ebuilds:
1. env-update reads 20java
2. 20java points into system-vm
3. system-vm is set by java-config to point to jdk
4. jdk provides env settings
5. env settings provide access to java, javac and so on

Now we have for the same old ebuilds:
1. env-update reads 20java
2. 20java sets env settings
3. env settings provide access to wrappers
4. wrappers use system-vm
5. system-vm set by java-config


Greetings,
 Martin von Gagern

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]