1 |
I would like to commit a new java eclass within the next week. |
2 |
|
3 |
This eclass is designed to support the functionality that Betelgeuse |
4 |
outlined within a previous post.[1] |
5 |
|
6 |
As you will be able to see, this eclass is very simple and only uses |
7 |
functionality that will be provided by the java-utils-2.eclass (see the |
8 |
attached patch ) |
9 |
|
10 |
Basically all the happens is that a file is created under |
11 |
/usr/share/java-config-2/virtuals/ |
12 |
that contains (at present) 3 variables. This file is then read by our |
13 |
java-config-2 application. |
14 |
|
15 |
|
16 |
The eclass is currently implemented within the java-virtuals overlay for |
17 |
those who are interested |
18 |
|
19 |
https://overlays.gentoo.org/svn/proj/java/java-virtuals/ |
20 |
|
21 |
|
22 |
Any suggestions, improvements and of course approvals will be gladly |
23 |
accepted |
24 |
|
25 |
Go the All Blacks!! |
26 |
|
27 |
Alistair |
28 |
|
29 |
|
30 |
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/48932/focus=48933 |
31 |
|
32 |
On Sun, 29 Apr 2007 17:00:09 +0200, Petteri Räty wrote: |
33 |
|
34 |
> We want to implement virtuals for Java at some point and for that we |
35 |
> need to know the package that provides the virtual because some virtuals |
36 |
> can be provided by the JDK or normal packages and this affects the JDK |
37 |
> selection at build time. One option is to call into Portage to find this |
38 |
> out, but of course Paludis and Pkgcore people most likely don't like |
39 |
> this approach. One thing that comes to mind is to allow for virtuals to |
40 |
> install files so we can install the provider information in a format |
41 |
> easy for us. We need the information in format ${PN}-${SLOT} because |
42 |
> that's the way we install in /usr/share. So do you think it's ok for |
43 |
> virtuals to install files (we can of course call the category |
44 |
> java-virtual/ too), should we call Portage code, or do you have an |
45 |
> another idea? |