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
|
