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@l.g.o mailing list