1 |
This message about java-config just passed across gentoo-dev. Apparently |
2 |
it can switch both on a system and a user level, so it may be worth |
3 |
looking into for adapting to mpi-config. |
4 |
|
5 |
Thanks, |
6 |
Donnie |
7 |
|
8 |
-------- Original Message -------- |
9 |
Subject: [gentoo-dev] Changes to the way Java packages are built |
10 |
Date: Sun, 18 Jun 2006 10:39:06 -0500 |
11 |
From: Joshua Nichols <nichoj@g.o> |
12 |
Reply-To: gentoo-dev@l.g.o |
13 |
To: gentoo-dev@l.g.o |
14 |
|
15 |
= Background = |
16 |
|
17 |
As some might have noticed, Java 1.5 has been package.masked for some |
18 |
time now. There are a number of issues introduced with 1.5 that have |
19 |
kept it in package.mask. Please see the Java 1.5 FAQ [1] for more details. |
20 |
|
21 |
[1] http://www.gentoo.org/proj/en/java/tiger-faq.xml |
22 |
|
23 |
About a year ago, work was begun on improving our part of the build |
24 |
system (read: Java related eclasses and our java-config tool) in a way |
25 |
to make it much more flexible in general, but specifically improve it to |
26 |
get around the known issues. It took about six months to fully develop. |
27 |
Unfortunately, the new system was not quite a drop-in replacement. So, |
28 |
it took from then until now to determine how to migrate from the current |
29 |
system to the new one in a sane way. |
30 |
|
31 |
|
32 |
= The Current System = |
33 |
|
34 |
To give some proper background, it is worth going over the current |
35 |
system briefly. |
36 |
|
37 |
== The Java Virtual Machine == |
38 |
Each Java Virtual Machine (VM) installs an environment file into |
39 |
/etc/env.d/java. These files contain information about where JAVA_HOME |
40 |
is, the PATH to include, etc. |
41 |
|
42 |
VMs traditionally get installed at /opt/${P} |
43 |
|
44 |
We have the concept of a 'system' VM and a 'user' VM. The system VM is |
45 |
the default VM that will be used for root, and for users who haven't |
46 |
selected a user VM. The user VM is, as one might guess, selected on a |
47 |
per user basis. It is worth noting that root always uses the system VM, |
48 |
and as a result, packages use the system VM when being merged by emerge. |
49 |
|
50 |
java-config is used to set the system and user VM. When you do so, the |
51 |
appropriate file from /etc/env.d/java is copied to/etc/env.d/20java for |
52 |
the system VM or to ~/.gentoo/java-env for the user VM. |
53 |
|
54 |
java-config's notion of the current VM is tied entirely to the |
55 |
environment, specifically to JAVA_HOME. Therefore, if you change the |
56 |
system VM, you'd need to run env-update and then resource /etc/profile. |
57 |
Likewise, changing the user VM involves sourcing ~/.gentoo/java-env. |
58 |
|
59 |
The fact that you're tied to the environment is annoying, because as |
60 |
mentioned, you need re-source the appropriate files. Now imagine you |
61 |
have a ton of terminals open... you'd have to source the environment |
62 |
files from each one. |
63 |
|
64 |
== Packages == |
65 |
|
66 |
When a Java package is built, information about it is saved in |
67 |
/usr/share/${PN}-${SLOT}/package.env (or /usr/share/${PN}/package.env if |
68 |
SLOT == 0). In particular, the jars that are associated with the package |
69 |
are recorded, as well as which jars from other packages are used. |
70 |
java-config can later be used to query for this information. |
71 |
|
72 |
== Eclasses == |
73 |
|
74 |
There are currently 3 eclasses: java, java-pkg, and java-utils. |
75 |
|
76 |
java.eclass is used for packages which provide a VM. |
77 |
java-pkg.eclass is used for most Java packages. It provides tools for |
78 |
querying installed jars, and for installing various Java related files. |
79 |
java-utils.eclass provides a few utility functions for dealing with Java |
80 |
stuff. |
81 |
|
82 |
= The New System = |
83 |
|
84 |
== The Java Virtual Machine == |
85 |
In addition to the concept of a system and a user VM, the new system has |
86 |
a build VM. As the name implies, the build VM is used for building |
87 |
packages (instead of the system VM). Sane defaults are defined on a per |
88 |
platform basis at /usr/share/java-config-2/config/jdk-defaults.conf [3]. |
89 |
The build VM can further be configured by |
90 |
/etc/java-config-2/build/jdk.conf [4] . |
91 |
|
92 |
[3] |
93 |
https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk-defaults-x86.conf |
94 |
[4] |
95 |
https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk.conf |
96 |
|
97 |
For each Java release (ie 1.3, 1.4, 1.5, etc), you can specify which |
98 |
vendor and version to use at build time. |
99 |
|
100 |
In addition to being installed to /opt/${P}, VMs also now have a symlink |
101 |
in /usr/lib/jvm/${PN}-${SLOT}. The purpose of these symlinks is |
102 |
explained further down. |
103 |
|
104 |
The user and system VMs are now represented by symlinks pointing to VMs |
105 |
located in /usr/lib/jvm/. The system VM lives at |
106 |
/etc/java-config-2/current-system-vm, and the user VM at |
107 |
~/.gentoo/java-config-2/current-user-vm . Additionally, an environment |
108 |
variable, GENTOO_VM, can be used to specify the VM used at a given |
109 |
instance. GENTOO_VM should be the name of a VM located in /usr/lib/jvm. |
110 |
So with regard to what VM is used, first GENTOO_VM is checked, then the |
111 |
user VM (for non-root users), and then lastly the system VM. |
112 |
|
113 |
|
114 |
All the trusty java binaries, ie java, javac, javadoc, jar, etc, now get |
115 |
wrappers installed into /usr/bin. These are actually symlinks to |
116 |
/usr/bin/run-java-tool. This is a script which will figure out which |
117 |
tool was invoked, and then determine which VM to used using the method |
118 |
mentioned above. |
119 |
|
120 |
== Packages == |
121 |
|
122 |
We now save more information about the build environment at build time |
123 |
for each package. This information is saved at |
124 |
/usr/share/${PN}-${SLOT}/package.env. This is facilitate troubleshooting |
125 |
bugs. Specially, we collect the VM dependency is (ie >=virtual/jdk-1.4), |
126 |
what -source and -target were used , and which VM. We also keep track of |
127 |
where javadocs get installed, and where Java sources get installed, |
128 |
which are useful for integrating into IDEs like netbeans and eclipse. |
129 |
|
130 |
== Eclasses == |
131 |
|
132 |
For each eclass we previously had, we have a updated version of the |
133 |
eclass, in addition to a few totally new eclasses. |
134 |
|
135 |
java-utils-2.eclass |
136 |
A utility eclass. All utility functions live here (as opposed to being |
137 |
spread between java-pkg and java-utils). Among other things, there are |
138 |
functions for figuring out which VM should be used for building, based |
139 |
on the DEPEND of a package (ie the virtual/jdk atom), and set GENTOO_VM |
140 |
accordingly. |
141 |
|
142 |
java-pkg-2.eclass |
143 |
The eclass the Java-only packages should inherit. It uses phase hooks |
144 |
in order to make sure that the environment is setup properly for each phase. |
145 |
|
146 |
java-pkg-opt-2.eclass |
147 |
Similar to java-pkg-2, except this is for packages that have optional |
148 |
Java support, ie a USE flag. Phase hooks are again used to ensure the |
149 |
environment is setup properly for each phase. |
150 |
|
151 |
java-ant-2.eclass |
152 |
Packages that build using ant should inherit this eclass. Essentially, |
153 |
this is eclass will ensure that build.xml files get rewritten such that |
154 |
javac tasks have the right source and target attributes. In other words, |
155 |
it makes sure that the right version bytecode gets compiled. |
156 |
|
157 |
java-vm-2.eclass |
158 |
This is the successor to java.eclass, but more aptly name. |
159 |
|
160 |
= Letting the Systems Coexist = |
161 |
|
162 |
Originally, the new eclasses were a replacement for the current |
163 |
eclasses, ie java-pkg-2 used to still be java-pkg, and java-utils-2 used |
164 |
to be still be java-utils. Additionally, java-config was unslotted, so |
165 |
the new version of it replaced the current one. Unfortunately, it was |
166 |
realized that the new system was not a 100% drop-in replacement for the |
167 |
current one, so we set forth with the task to find a way to migrate from |
168 |
one to the other. |
169 |
|
170 |
The method we decided on was to have the concept of having a |
171 |
'generation' for each system, where the generation consists of the |
172 |
eclasses, a version of java-config, and the tools that support it. To |
173 |
cope with java-config, it is now slotted, and installs |
174 |
/usr/bin/java-config-<insert generation here> . There is then a wrapper |
175 |
for java-config at /usr/bin/java-config, which reads a variable |
176 |
WANT_JAVA_CONFIG to determine which java-config to use, or if not |
177 |
specified, the most recent version. The eclasses then export the |
178 |
appropriate value of WANT_JAVA_CONFIG to get the right version of |
179 |
java-config they need. |
180 |
|
181 |
The existing eclasses and java-config-1.x will be 'generation 1'. The |
182 |
new eclasses and java-config-2.x will be 'generation 2'. |
183 |
|
184 |
The first packages to be migrated to generation 2 will be the VMs. When |
185 |
installed, they will also install environment files that are compatible |
186 |
with generation 1. This will allow you to have both a system VM for |
187 |
generation 1, in addition to the system and build VM for generation 2. |
188 |
The consequence of this is that ebuilds using generation 1 will continue |
189 |
to build/run as they previously did, while allowing packages to be |
190 |
migrated to use generation 2 on a package-by-package basis. So, all |
191 |
existing ebuilds will continue to work, and will be replaced |
192 |
incrementally during our migration. |
193 |
|
194 |
A note on Java 1.5 here... The 1.5 JDKs don't install a generation-1 |
195 |
compatible environment file. This is to prevent the problems already |
196 |
describe with 1.5, and should prevent them from happening. At this |
197 |
point, we should be able to unmask the 1.5 JDKs. So 1.5 will be |
198 |
available, but only to generation-2 packages. |
199 |
|
200 |
The next packages to be migrated will be ones that need the features of |
201 |
the new generation. In particular, this means packages which need Java |
202 |
1.5 to build and/or run. |
203 |
|
204 |
Once these packages have been migrated, the rest of the tree which uses |
205 |
Java will be migrated as expediently as possible. I've written some |
206 |
notes about how to migrate over on our wiki [5] |
207 |
[5] https://projects.gentooexperimental.org/expj/wiki/Migrating_packages |
208 |
|
209 |
= Using the new system = |
210 |
|
211 |
I have written documentation on switching to the new system, from the |
212 |
user's perspective, over at our wiki [6] |
213 |
|
214 |
[6] |
215 |
https://projects.gentooexperimental.org/expj/wiki/Using_migration-overlay |
216 |
|
217 |
= Feedback = |
218 |
|
219 |
Obviously, these aren't exactly light changes that need to be made. |
220 |
Therefore, it's important to get as much feedback as possible, and to |
221 |
make the upgrade process as smooth as possible. |
222 |
|
223 |
I'd hope to get these changes put into the tree in the next week or two, |
224 |
pending feedback. This development has been a long time in the making, |
225 |
and the Java 1.5 problem has been a thorn in our side for long enough. |
226 |
-- |
227 |
gentoo-dev@g.o mailing list |