[gentoo-java] Java 1.5 migration plans

[Joshua Nichols]

I've been recently trying to work out a few possible plans for migrating 
axxo-overlay into the main portage tree. To give a quick synopsis, the 
migration of axxo-overlay needs to involve:

* A recent portage. We need features out of portage-2.1_pre1 to for all 
the new features of the overlay to work.
* A new version of java-config. Among other things, the new java-config 
uses symlinks, instead of environment variables, for controlling the 
current VM. This allows us do some magic like merge-time VM switching.
* A new version of javatoolkit. This new version provides tools for 
rewriting ant scripts, so that we can have sane -target/-source 
attributes of javac tasks.
* New eclasses. In addition to java.eclass (for installing Vms), 
java-pkg.eclass (for Java packages), and java-utils.eclass (provides 
some methods for checking what VM is being used), we have added 
java-ant.eclass (for Ant based packages) and java-pkg-opt.eclass (for 
packages which only have optional support for Java). Additionally, most 
functions that currently live in java-pkg have moved to java-utils.

Now, migration to the new overlay certainly has a few obstacles.
* The new eclasses require the new java-config and javatoolkit. So, this 
means that that they would need to be stabilized before we could migrate 
to the new eclasses. However, they are not quite 100% backward 
compatible. So therefore, it's a bit difficult to stabilize java-config 
and javatoolkit if we can't use them with the current system
* Can we migrate ~arch and arch seperately, or do they need to be done 
at the same time?

And so, I have to possible plans, with one plan being a slight variation 
of the other. I've divided them into separate phases. From here on, I'm 
going to be assuming you are familiar with the existing system and 
somewhat familiar with axxo-overlay.

Here's the first plan:
----------------------------------------

Phase 1 (can be concurrent with Phase 2)
Prereqs: everyone in java herd agrees on plan

1) bring over new java.eclass and jdk's and jre's
    - we should be able to just drop the in place of existing ones for 
stable and testing, but would need to do version bumps to make sure 
users get the new style env files.

2) bring over new java-config, javatoolkit
    - This seems to be backward compatible for most purposes.
should check for old style configs and die bitterly if they are around
NOTE: this may break a few packages. This happens because we've 
introduced wrapper scripts at /usr/bin/{java,javac,etc}. The problem is 
that some packages might try to be smart, and try to figure out 
JAVA_HOME from the location of java.

----------------------------------------

Phase 2 (can be concurrent with Phase 1):
Prereqs: everyone in java herd agrees on plan

1) bring over new java-utils.eclass
    - ensure packages which use it will continue work
    - don't bring over (because they need stable java-config)
        get-source/target, or anything that uses them
        new is-vm-version-sufficient and anything that uses them
        dolauncher
        java-pkg_die
        java-pkg_need
        
    
2) add new skeleton implementations of new eclasses: java-ant, java-pkg-opt:
    - for now should both inherit java-pkg and java-utils
    - ant_src_unpack for java-ant, and make all ant-based ebuilds use it

3) Implement skelton ejavac and eant in java-utils
    - should only call ant/javac
    - push back -source/-target stuff till
    - Update all ebuilds to use these instead of javac/ant

4) migrate junit use flag to test use flag, and perform tests in src_test

5) remove jikes use flag
    - should also put java-pkg_filter-compiler on things that are known 
not to
        - filter jikes on things that are known not to like jikes

-------------------------------------------

Phase 3
Prereqs: Phase 1 and 2, java-config and javatoolkit have been marked 
stable everywhere

1) Migrate everything from java-utils that was dropped during Phase 2
    Migrate real implemenation of ejavac, ie add appropriate -source/-target
    Migrate dolauncher support
    Migrate java-pkg_need / virtuals

1) Migrate rewriting build.xml's to java-ant

-------------------------------------------

Phase 4:
Prereqs: Phase 3, a version of portage has been marked stable on all 
platforms that have and use java

1) Migrate merge-time vm switching
2) Migrate java-pkg_die
----------------------------------------




And here's the second plan:
----------------------------------------

Phase 1 (can be concurrent with Phase 2)
Prereqs: everyone in java herd agrees on plan

1) Migrate new java.eclass and jdk's and jre's
    - we should be able to just drop the in place of existing ones for 
stable and testing, but would need to do version bumps to make sure 
users get the new style env files.

2) Introduce new java-config and javatoolkit
    - This seems to be backward compatible for most purposes.
        - should check for old style configs and die bitterly if they 
are around

----------------------------------------

Phase 2 (can be concurrent with Phase 1):
Prereqs: everyone in java herd agrees on plan

1) Add new skeleton implementations of new eclasses: java-ant, java-pkg-opt:
    - for now should both inherit java-pkg and java-utils
    - ant_src_unpack for java-ant, and make all ant-based ebuilds use it

2) Implement skelton ejavac and eant in java-utils
    - should only call ant/javac
    - push back -source/-target stuff till
    - Update all ebuilds to use these instead of javac/ant

3) Migrate junit use flag to test use flag, and perform tests in src_test

4) Remove jikes use flag
    - should also put java-pkg_filter-compiler on things that are known 
not to
        - filter jikes on things that are known not to like jikes

-------------------------------------------

Phase 3
Prereqs: Phase 1 and 2, java-config and javatoolkit have been marked 
stable everywhere

1) Migrate new java-utils.eclass
1) Migrate rewriting build.xml's to java-ant

-------------------------------------------

Phase 4:
Prereqs: Phase 3, a version of portage has been marked stable on all 
platforms that have and use java

1) Migrate merge-time vm switching
2) Migrate java-pkg_die



---------------------------------------------

The main difference between the two is how java-utils gets migrated. In 
the first scenario, we migrate everything which doesn't need the new 
java-config and javatoolkit, whereas in the second, we migrate all of 
java-utils at once after java-config and javatoolkit have been stabilized.

I currently prefer the first one. This allows us to get the new eclass 
functionality that we want, and current ebuilds should (mostly) continue 
to work with the old style functionality. By doing it this way, we can 
our time adopting the new functionality (not that I want this to take 
long, but we wouldn't have to immediately change everything).

I know Thomas had another plan, as well as some concerns with these plans.


Regards,

Josh
-- 
gentoo-java@g.o mailing list