From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1EsEEx-00088J-QW for garchives@archives.gentoo.org; Fri, 30 Dec 2005 06:59:52 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBU6x6HC015538; Fri, 30 Dec 2005 06:59:06 GMT Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.62]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBU6x5KB010066 for ; Fri, 30 Dec 2005 06:59:05 GMT Received: from 146-115-26-214.c3-0.abr-ubr1.sbo-abr.ma.cable.rcn.com (HELO [192.168.1.104]) ([146.115.26.214]) by smtp02.mrf.mail.rcn.net with ESMTP; 30 Dec 2005 01:59:04 -0500 X-IronPort-AV: i="3.99,313,1131339600"; d="scan'208"; a="189996287:sNHT27669320" Message-ID: <43B4DAB3.5050309@gentoo.org> Date: Fri, 30 Dec 2005 01:58:59 -0500 From: Joshua Nichols User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051223) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-Version: 1.0 To: gentoo-java@lists.gentoo.org Subject: [gentoo-java] Java 1.5 migration plans Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: ad8c07ee-d6cf-4f4d-8f8b-f9bfcfca5e1e X-Archives-Hash: 2c37d94b8546ddd06b067ab8fb1b6715 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@gentoo.org mailing list