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
Message-Id: 20051230194027.GA10036@ytpme.telenet.be
In Reply to: [gentoo-java] Java 1.5 migration plans by Joshua Nichols
1 > Phase 1 (can be concurrent with Phase 2)
2 > Prereqs: everyone in java herd agrees on plan
3 >
4 > 1) bring over new java.eclass and jdk's and jre's
5 > - we should be able to just drop the in place of existing ones for
6 > stable and testing, but would need to do version bumps to make sure
7 > users get the new style env files.
8 >
9 > 2) bring over new java-config, javatoolkit
10 > - This seems to be backward compatible for most purposes.
11 > should check for old style configs and die bitterly if they are around
12 > NOTE: this may break a few packages. This happens because we've
13 > introduced wrapper scripts at /usr/bin/{java,javac,etc}. The problem is
14 > that some packages might try to be smart, and try to figure out
15 > JAVA_HOME from the location of java.
16
17 In the current state i believe it will break more.
18 Since it won't export any of the variables anymore.
19 So these changes would need to be introduced at the same times as the
20 ebuild fixes
21
22 > ----------------------------------------
23 >
24 > Phase 2 (can be concurrent with Phase 1):
25 > Prereqs: everyone in java herd agrees on plan
26 >
27 > 1) bring over new java-utils.eclass
28 > - ensure packages which use it will continue work
29 > - don't bring over (because they need stable java-config)
30 > get-source/target, or anything that uses them
31 > new is-vm-version-sufficient and anything that uses them
32 > dolauncher
33 > java-pkg_die
34 > java-pkg_need
35
36 That doesn't leave alot :)
37
38
39 > 2) add new skeleton implementations of new eclasses: java-ant, java-pkg-opt:
40 > - for now should both inherit java-pkg and java-utils
41 > - ant_src_unpack for java-ant, and make all ant-based ebuilds use it
42 >
43 > 3) Implement skelton ejavac and eant in java-utils
44 > - should only call ant/javac
45 > - push back -source/-target stuff till
46 > - Update all ebuilds to use these instead of javac/ant
47 >
48 > 4) migrate junit use flag to test use flag, and perform tests in src_test
49 >
50 > 5) remove jikes use flag
51 > - should also put java-pkg_filter-compiler on things that are known
52 > not to
53 > - filter jikes on things that are known not to like jikes
54
55 I'm still not happy with the filtering, It was discusses somewhere, but
56 i can't find it anymore. If everyone else things its a good idea, i'll
57 accept it
58
59 >
60 > -------------------------------------------
61 >
62 > Phase 3
63 > Prereqs: Phase 1 and 2, java-config and javatoolkit have been marked
64 > stable everywhere
65 >
66 > 1) Migrate everything from java-utils that was dropped during Phase 2
67 > Migrate real implemenation of ejavac, ie add appropriate -source/-target
68 > Migrate dolauncher support
69 > Migrate java-pkg_need / virtuals
70 >
71 > 1) Migrate rewriting build.xml's to java-ant
72 >
73 > -------------------------------------------
74 >
75 > Phase 4:
76 > Prereqs: Phase 3, a version of portage has been marked stable on all
77 > platforms that have and use java
78 >
79 > 1) Migrate merge-time vm switching
80 > 2) Migrate java-pkg_die
81 > ----------------------------------------
82
83 Its not clear to me when you want to do the ebuilds changes, and to arch
84 or ~arch. or both?
85
86 Since for everything to be merged, all ebuild updated need to be done,
87 and keyworded stable.
88
89 If let this be done over time, it'll be another few years before 1.5 can
90 unmasked. Which can only be done after phase 4. And all previous non
91 updated ebuilds removed.
92
93 > I know Thomas had another plan, as well as some concerns with these plans.
94
95 I don't really have a plan, i was trying to come up with a way that
96 would keep breakage to a minimum and keep everyone happy.
97
98 I wasn't able to come up with one.
99
100 I'd prefer to just merge everything in one shot, but some people may
101 completely block that (possibly rightly so).
102
103 - 1.5 Needed things, such as merge time vm switching and,
104 -target/-source forcing
105 - And then the eant/launcher/cleanups
106 Which are both interlinked
107
108 Another option i have been thinking about would be:
109
110 Revert the new java-config to behave like the old one, or add some of
111 the new functionality in the old one (Not something i will do, so we
112 would need someone else for that). Making it 100% backwards compatible.
113 Rev bump all the jdk/jre with the environment files.
114
115 Update the eclasses in tree to include eant/ajavac/launcher, and the
116 target/source things.
117
118 Then first, update all ~arch ebuilds to use this newness. So it can be
119 tested. Say 2 weeks max.
120 Then apply the same to arch ebuilds, because we like consistency.
121
122 During this time frame, we also get aproval from the maintainers of
123 packages we need to touch. We'll need to write a doc explaining them why
124 the changes are needed. Can probbaly be scraped from our docs in README/*.
125
126 Then in a one shot operation, we add the new java-config with /usr/bin/*
127 symlinks, and no longer export the vars. Then update all the ebuilds to
128 support merge time switching. arch and ~arch.
129 If we only add it to ~arch, then arch ebuilds will be broken for ~arch,
130 and vice versa.
131
132 After this, unmask 1.5. Sit back and get flamed about tomcat 5.5
133
134
135 Not sure if this is a good option, best i can come up and try to keep
136 everyone happy, may be forgetting something aswel.
137
138
139 --
140 Thomas Matthijs (axxo, knu)
141 --
142 gentoo-java@g.o mailing list

Replies

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>