Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-java
Navigation:
Lists: gentoo-java: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-java@g.o
From: Thomas Matthijs <axxo@g.o>
Subject: Re: Java 1.5 migration plans
Date: Fri, 30 Dec 2005 20:40:27 +0100
> 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


Replies:
Re: Java 1.5 migration plans
-- Martin von Gagern
Re: Java 1.5 migration plans
-- Petteri R├Ąty
References:
Java 1.5 migration plans
-- Joshua Nichols
Navigation:
Lists: gentoo-java: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Java 1.5 migration plans
Next by thread:
Re: Java 1.5 migration plans
Previous by date:
Re: ideas for packages which use maven to build
Next by date:
Re: Java 1.5 migration plans


Updated Jun 17, 2009

Summary: Archive of the gentoo-java mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.