1 |
I've been recently trying to work out a few possible plans for migrating |
2 |
axxo-overlay into the main portage tree. To give a quick synopsis, the |
3 |
migration of axxo-overlay needs to involve: |
4 |
|
5 |
* A recent portage. We need features out of portage-2.1_pre1 to for all |
6 |
the new features of the overlay to work. |
7 |
* A new version of java-config. Among other things, the new java-config |
8 |
uses symlinks, instead of environment variables, for controlling the |
9 |
current VM. This allows us do some magic like merge-time VM switching. |
10 |
* A new version of javatoolkit. This new version provides tools for |
11 |
rewriting ant scripts, so that we can have sane -target/-source |
12 |
attributes of javac tasks. |
13 |
* New eclasses. In addition to java.eclass (for installing Vms), |
14 |
java-pkg.eclass (for Java packages), and java-utils.eclass (provides |
15 |
some methods for checking what VM is being used), we have added |
16 |
java-ant.eclass (for Ant based packages) and java-pkg-opt.eclass (for |
17 |
packages which only have optional support for Java). Additionally, most |
18 |
functions that currently live in java-pkg have moved to java-utils. |
19 |
|
20 |
Now, migration to the new overlay certainly has a few obstacles. |
21 |
* The new eclasses require the new java-config and javatoolkit. So, this |
22 |
means that that they would need to be stabilized before we could migrate |
23 |
to the new eclasses. However, they are not quite 100% backward |
24 |
compatible. So therefore, it's a bit difficult to stabilize java-config |
25 |
and javatoolkit if we can't use them with the current system |
26 |
* Can we migrate ~arch and arch seperately, or do they need to be done |
27 |
at the same time? |
28 |
|
29 |
And so, I have to possible plans, with one plan being a slight variation |
30 |
of the other. I've divided them into separate phases. From here on, I'm |
31 |
going to be assuming you are familiar with the existing system and |
32 |
somewhat familiar with axxo-overlay. |
33 |
|
34 |
Here's the first plan: |
35 |
---------------------------------------- |
36 |
|
37 |
Phase 1 (can be concurrent with Phase 2) |
38 |
Prereqs: everyone in java herd agrees on plan |
39 |
|
40 |
1) bring over new java.eclass and jdk's and jre's |
41 |
- we should be able to just drop the in place of existing ones for |
42 |
stable and testing, but would need to do version bumps to make sure |
43 |
users get the new style env files. |
44 |
|
45 |
2) bring over new java-config, javatoolkit |
46 |
- This seems to be backward compatible for most purposes. |
47 |
should check for old style configs and die bitterly if they are around |
48 |
NOTE: this may break a few packages. This happens because we've |
49 |
introduced wrapper scripts at /usr/bin/{java,javac,etc}. The problem is |
50 |
that some packages might try to be smart, and try to figure out |
51 |
JAVA_HOME from the location of java. |
52 |
|
53 |
---------------------------------------- |
54 |
|
55 |
Phase 2 (can be concurrent with Phase 1): |
56 |
Prereqs: everyone in java herd agrees on plan |
57 |
|
58 |
1) bring over new java-utils.eclass |
59 |
- ensure packages which use it will continue work |
60 |
- don't bring over (because they need stable java-config) |
61 |
get-source/target, or anything that uses them |
62 |
new is-vm-version-sufficient and anything that uses them |
63 |
dolauncher |
64 |
java-pkg_die |
65 |
java-pkg_need |
66 |
|
67 |
|
68 |
2) add new skeleton implementations of new eclasses: java-ant, java-pkg-opt: |
69 |
- for now should both inherit java-pkg and java-utils |
70 |
- ant_src_unpack for java-ant, and make all ant-based ebuilds use it |
71 |
|
72 |
3) Implement skelton ejavac and eant in java-utils |
73 |
- should only call ant/javac |
74 |
- push back -source/-target stuff till |
75 |
- Update all ebuilds to use these instead of javac/ant |
76 |
|
77 |
4) migrate junit use flag to test use flag, and perform tests in src_test |
78 |
|
79 |
5) remove jikes use flag |
80 |
- should also put java-pkg_filter-compiler on things that are known |
81 |
not to |
82 |
- filter jikes on things that are known not to like jikes |
83 |
|
84 |
------------------------------------------- |
85 |
|
86 |
Phase 3 |
87 |
Prereqs: Phase 1 and 2, java-config and javatoolkit have been marked |
88 |
stable everywhere |
89 |
|
90 |
1) Migrate everything from java-utils that was dropped during Phase 2 |
91 |
Migrate real implemenation of ejavac, ie add appropriate -source/-target |
92 |
Migrate dolauncher support |
93 |
Migrate java-pkg_need / virtuals |
94 |
|
95 |
1) Migrate rewriting build.xml's to java-ant |
96 |
|
97 |
------------------------------------------- |
98 |
|
99 |
Phase 4: |
100 |
Prereqs: Phase 3, a version of portage has been marked stable on all |
101 |
platforms that have and use java |
102 |
|
103 |
1) Migrate merge-time vm switching |
104 |
2) Migrate java-pkg_die |
105 |
---------------------------------------- |
106 |
|
107 |
|
108 |
|
109 |
|
110 |
And here's the second plan: |
111 |
---------------------------------------- |
112 |
|
113 |
Phase 1 (can be concurrent with Phase 2) |
114 |
Prereqs: everyone in java herd agrees on plan |
115 |
|
116 |
1) Migrate new java.eclass and jdk's and jre's |
117 |
- we should be able to just drop the in place of existing ones for |
118 |
stable and testing, but would need to do version bumps to make sure |
119 |
users get the new style env files. |
120 |
|
121 |
2) Introduce new java-config and javatoolkit |
122 |
- This seems to be backward compatible for most purposes. |
123 |
- should check for old style configs and die bitterly if they |
124 |
are around |
125 |
|
126 |
---------------------------------------- |
127 |
|
128 |
Phase 2 (can be concurrent with Phase 1): |
129 |
Prereqs: everyone in java herd agrees on plan |
130 |
|
131 |
1) Add new skeleton implementations of new eclasses: java-ant, java-pkg-opt: |
132 |
- for now should both inherit java-pkg and java-utils |
133 |
- ant_src_unpack for java-ant, and make all ant-based ebuilds use it |
134 |
|
135 |
2) Implement skelton ejavac and eant in java-utils |
136 |
- should only call ant/javac |
137 |
- push back -source/-target stuff till |
138 |
- Update all ebuilds to use these instead of javac/ant |
139 |
|
140 |
3) Migrate junit use flag to test use flag, and perform tests in src_test |
141 |
|
142 |
4) Remove jikes use flag |
143 |
- should also put java-pkg_filter-compiler on things that are known |
144 |
not to |
145 |
- filter jikes on things that are known not to like jikes |
146 |
|
147 |
------------------------------------------- |
148 |
|
149 |
Phase 3 |
150 |
Prereqs: Phase 1 and 2, java-config and javatoolkit have been marked |
151 |
stable everywhere |
152 |
|
153 |
1) Migrate new java-utils.eclass |
154 |
1) Migrate rewriting build.xml's to java-ant |
155 |
|
156 |
------------------------------------------- |
157 |
|
158 |
Phase 4: |
159 |
Prereqs: Phase 3, a version of portage has been marked stable on all |
160 |
platforms that have and use java |
161 |
|
162 |
1) Migrate merge-time vm switching |
163 |
2) Migrate java-pkg_die |
164 |
|
165 |
|
166 |
|
167 |
--------------------------------------------- |
168 |
|
169 |
The main difference between the two is how java-utils gets migrated. In |
170 |
the first scenario, we migrate everything which doesn't need the new |
171 |
java-config and javatoolkit, whereas in the second, we migrate all of |
172 |
java-utils at once after java-config and javatoolkit have been stabilized. |
173 |
|
174 |
I currently prefer the first one. This allows us to get the new eclass |
175 |
functionality that we want, and current ebuilds should (mostly) continue |
176 |
to work with the old style functionality. By doing it this way, we can |
177 |
our time adopting the new functionality (not that I want this to take |
178 |
long, but we wouldn't have to immediately change everything). |
179 |
|
180 |
I know Thomas had another plan, as well as some concerns with these plans. |
181 |
|
182 |
|
183 |
Regards, |
184 |
|
185 |
Josh |
186 |
-- |
187 |
gentoo-java@g.o mailing list |