Re: Virtual troubles

Vlastimil Babka wrote:
 > Alistair Bush wrote:
 >> Have update java-config to (hopefully) do both :)
 >
 > Good :)
 >
 >> Basically this means that if package is to be suitable for
 >> java-virtualizing then it must provide a jar that is similarly (or
 >> more exactly 'exactly') named as every other providers ${API}.jar
 >>
 >> javamail -> mail.jar
 >> servlet-api -> serlvetapi.jar jsp.jar
 >> grandma's special recipe -> gsr.jar
 >
 > OK. Perhaps the name of the 'special' jar should be declared as variable
 > in the virtual's ebuild and recorded in virtual's file? Are there any
 > uses for this besides a potential java-check-environment check? :)
 > Perhaps a 'java-pkg_getjars --virtual' would automatically give you this
 >  jar only? But then it wouldn't be really getjarS, probably even more
 > confusing than now. So maybe not getjars, but a 'java-pkg_getjar
 > --virtual javamail' would let you omit the jarname.

So --virtual would give the API jar file.  Mmmm... interesting suggestion

 >
 > And what about virtual provided by the VM, which jar will I get? rt.jar?

virtuals providing vms currently have 2 variables,  one a list of 
providers, the other is a relative path from ${JAVA_HOME}.  therefore 
combining a vm's JAVA_HOME with PROVIDER_JAR to form the classpath.

Therefore the only requirement is that the jar is named the same across 
vm instances. (it should be noted that currently we support jar, not jars)

 >
 > Caster
 >
-- 
[email protected] mailing list