[gentoo-java] Virtual troubles

[gentoo-java] Virtual troubles

[Vlastimil Babka]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Discovered some problems with virtuals today.

First one is in the depend-java-query tool, which can't correctly parse
dependencies as =java-virtuals/servlet-api-2.3* - transforms to
"servlet-api-2.3*" which it can't find, and raises exception - see how
it ends up in bug 205453 :) So, only deps like
"~java-virtuals/servlet-api-2.3" work. Should be fixed, or we decide to
go with slot deps and start sticking EAPI=1 in our ebuilds? I'm not sure
it can even parse 'java-virtuals/servlet-api:2.3' in current version :)

The other trouble I have is with eclass functions. It's confusing that
java-pkg_getjars() doesn't have --virtual parameter, but if you look
into what the parameter does, you realize it really doesn't need it.
Still, confusing :)
The worse trouble is with the functions that actually take the
parameter, java-pkg_jar-from $package $jar and java-pkg_getjar. By
passing --virtual, you say "I can't know what the particular provider's
jar names are, so depend on the whole package", but still you have to
pass an actual 'foo.jar' parameter. That's strange. What if there's new
provider with different jar name? What if the virtual is satisfied by
the VM itself? Suddenly you get an error, or am I wrong?

VB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkeI9zIACgkQtbrAj05h3oQy/wCfYfxKH7bV3DD7BTaTK3rg3r9o
JGgAn18nsjKZBebQUyi+tfK5vwYa9PbM
=tEpu
-----END PGP SIGNATURE-----
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] Virtual troubles

[Alistair Bush]

Vlastimil Babka wrote:
> Hi,
> 
> Discovered some problems with virtuals today.
:)
> 
> First one is in the depend-java-query tool, which can't correctly parse
> dependencies as =java-virtuals/servlet-api-2.3* - transforms to
> "servlet-api-2.3*" which it can't find, and raises exception - see how
> it ends up in bug 205453 :) So, only deps like
> "~java-virtuals/servlet-api-2.3" work. Should be fixed, or we decide to
> go with slot deps and start sticking EAPI=1 in our ebuilds? I'm not sure
> it can even parse 'java-virtuals/servlet-api:2.3' in current version :)

Have update java-config to (hopefully) do both :)

java-config -p package:slot works at least (is a little dump tho as 
package:0 won't currently work)

> 
> The other trouble I have is with eclass functions. It's confusing that
> java-pkg_getjars() doesn't have --virtual parameter, but if you look
> into what the parameter does, you realize it really doesn't need it.
> Still, confusing :)
> The worse trouble is with the functions that actually take the
> parameter, java-pkg_jar-from $package $jar and java-pkg_getjar. By
> passing --virtual, you say "I can't know what the particular provider's
> jar names are, so depend on the whole package", but still you have to
> pass an actual 'foo.jar' parameter. That's strange. What if there's new
> provider with different jar name? What if the virtual is satisfied by
> the VM itself? Suddenly you get an error, or am I wrong?

Let me clarify this as "I can't know the name of any implementing jars 
(if they are separate) but I do know the name of the api as that is fixed"

So basically

sun-javamail and gnu-javamail implement (surprise surprise) the javamail 
  api.  sun-javamail has one jar (mail.jar, API and Implementation) 
gnu-javamail has 2 (mail.jar, the API and another, the actual 
implementation)

so

java-pkg_jarfrom --virtual javamail mail.jar will retrieve mail.jar 
without recording the dependency as just that jar (as we can't know 
whether they are separate or not)

as the other functions don't record jar level deps the option is mute.

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
> 
> VB

Sorry It has taken me time to reply,  decided it was better to fix 
before explain.
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] Virtual troubles

[Vlastimil Babka]

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.

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

Caster

-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] Virtual troubles

[Alistair Bush]

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
 >
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] Virtual troubles

[Andrew Cowie]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Tue, 2008-01-15 at 00:24 +1300, Alistair Bush wrote:
> So --virtual would give the API jar file.  Mmmm... interesting suggestion

I don't mean to be dense, but the API / implementation .jar split is
fairly common. How about

        --api

? Might be a bit more discoverable from a tool usability perspective.

AfC
Sydney


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]