| 1 |
Vlastimil Babka wrote: |
| 2 |
> Alistair Bush wrote: |
| 3 |
>> Have update java-config to (hopefully) do both :) |
| 4 |
> |
| 5 |
> Good :) |
| 6 |
> |
| 7 |
>> Basically this means that if package is to be suitable for |
| 8 |
>> java-virtualizing then it must provide a jar that is similarly (or |
| 9 |
>> more exactly 'exactly') named as every other providers ${API}.jar |
| 10 |
>> |
| 11 |
>> javamail -> mail.jar |
| 12 |
>> servlet-api -> serlvetapi.jar jsp.jar |
| 13 |
>> grandma's special recipe -> gsr.jar |
| 14 |
> |
| 15 |
> OK. Perhaps the name of the 'special' jar should be declared as variable |
| 16 |
> in the virtual's ebuild and recorded in virtual's file? Are there any |
| 17 |
> uses for this besides a potential java-check-environment check? :) |
| 18 |
> Perhaps a 'java-pkg_getjars --virtual' would automatically give you this |
| 19 |
> jar only? But then it wouldn't be really getjarS, probably even more |
| 20 |
> confusing than now. So maybe not getjars, but a 'java-pkg_getjar |
| 21 |
> --virtual javamail' would let you omit the jarname. |
| 22 |
|
| 23 |
So --virtual would give the API jar file. Mmmm... interesting suggestion |
| 24 |
|
| 25 |
> |
| 26 |
> And what about virtual provided by the VM, which jar will I get? rt.jar? |
| 27 |
|
| 28 |
virtuals providing vms currently have 2 variables, one a list of |
| 29 |
providers, the other is a relative path from ${JAVA_HOME}. therefore |
| 30 |
combining a vm's JAVA_HOME with PROVIDER_JAR to form the classpath. |
| 31 |
|
| 32 |
Therefore the only requirement is that the jar is named the same across |
| 33 |
vm instances. (it should be noted that currently we support jar, not jars) |
| 34 |
|
| 35 |
> |
| 36 |
> Caster |
| 37 |
> |
| 38 |
-- |
| 39 |
gentoo-java@l.g.o mailing list |
Archives