| 1 |
Vytautas Jakutis kirjoitti: |
| 2 |
> On Sun, 29 Apr 2007 17:00:09 +0200, Petteri Räty wrote: |
| 3 |
> |
| 4 |
>> We want to implement virtuals for Java at some point and for that we |
| 5 |
>> need to know the package that provides the virtual because some virtuals |
| 6 |
>> can be provided by the JDK or normal packages and this affects the JDK |
| 7 |
>> selection at build time. One option is to call into Portage to find this |
| 8 |
>> out, but of course Paludis and Pkgcore people most likely don't like |
| 9 |
>> this approach. One thing that comes to mind is to allow for virtuals to |
| 10 |
>> install files so we can install the provider information in a format |
| 11 |
>> easy for us. We need the information in format ${PN}-${SLOT} because |
| 12 |
>> that's the way we install in /usr/share. So do you think it's ok for |
| 13 |
>> virtuals to install files (we can of course call the category |
| 14 |
>> java-virtual/ too), should we call Portage code, or do you have an |
| 15 |
>> another idea? |
| 16 |
> |
| 17 |
> The virtual ebuilds that utilize JAR service provider discovery mechanism |
| 18 |
> (in META-INF/services, from jdk1.4) should install its' API jars and use |
| 19 |
> virtual/ category. And those who don't - have to be patched to utilize or |
| 20 |
> have to use some special upwards compatibility layer (generate |
| 21 |
> some special metadata file and use special eclass)..? |
| 22 |
> |
| 23 |
|
| 24 |
Not really what we I am talking about. This is more ebuild related than |
| 25 |
Java platform. For example javax.management does not use the Provider |
| 26 |
style but it makes a good candidate for Java virtual ebuild. |
| 27 |
|
| 28 |
Regards, |
| 29 |
Petteri |
Archives