Gentoo Archives: gentoo-java

From: Thomas Matthijs <axxo@g.o>
To: gentoo-java@l.g.o
Subject: Re: [gentoo-java] Java 1.5 migration plans
Date: Fri, 30 Dec 2005 19:39:55
In Reply to: [gentoo-java] Java 1.5 migration plans by Joshua Nichols
> 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.
In the current state i believe it will break more. Since it won't export any of the variables anymore. So these changes would need to be introduced at the same times as the ebuild fixes
> ---------------------------------------- > > 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
That doesn't leave alot :)
> 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
I'm still not happy with the filtering, It was discusses somewhere, but i can't find it anymore. If everyone else things its a good idea, i'll accept it
> > ------------------------------------------- > > 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 > ----------------------------------------
Its not clear to me when you want to do the ebuilds changes, and to arch or ~arch. or both? Since for everything to be merged, all ebuild updated need to be done, and keyworded stable. If let this be done over time, it'll be another few years before 1.5 can unmasked. Which can only be done after phase 4. And all previous non updated ebuilds removed.
> I know Thomas had another plan, as well as some concerns with these plans.
I don't really have a plan, i was trying to come up with a way that would keep breakage to a minimum and keep everyone happy. I wasn't able to come up with one. I'd prefer to just merge everything in one shot, but some people may completely block that (possibly rightly so). - 1.5 Needed things, such as merge time vm switching and, -target/-source forcing - And then the eant/launcher/cleanups Which are both interlinked Another option i have been thinking about would be: Revert the new java-config to behave like the old one, or add some of the new functionality in the old one (Not something i will do, so we would need someone else for that). Making it 100% backwards compatible. Rev bump all the jdk/jre with the environment files. Update the eclasses in tree to include eant/ajavac/launcher, and the target/source things. Then first, update all ~arch ebuilds to use this newness. So it can be tested. Say 2 weeks max. Then apply the same to arch ebuilds, because we like consistency. During this time frame, we also get aproval from the maintainers of packages we need to touch. We'll need to write a doc explaining them why the changes are needed. Can probbaly be scraped from our docs in README/*. Then in a one shot operation, we add the new java-config with /usr/bin/* symlinks, and no longer export the vars. Then update all the ebuilds to support merge time switching. arch and ~arch. If we only add it to ~arch, then arch ebuilds will be broken for ~arch, and vice versa. After this, unmask 1.5. Sit back and get flamed about tomcat 5.5 Not sure if this is a good option, best i can come up and try to keep everyone happy, may be forgetting something aswel. -- Thomas Matthijs (axxo, knu) -- gentoo-java@g.o mailing list


Subject Author
Re: [gentoo-java] Java 1.5 migration plans "Petteri Räty" <betelgeuse@g.o>
Re: [gentoo-java] Java 1.5 migration plans Martin von Gagern <Martin.vGagern@×××.net>