[gentoo-dev] Virtuals and Java

[gentoo-dev] Virtuals and Java

[Petteri Räty]

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

We want to implement virtuals for Java at some point and for that we
need to know the package that provides the virtual because some virtuals
can be provided by the JDK or normal packages and this affects the JDK
selection at build time. One option is to call into Portage to find this
out, but of course Paludis and Pkgcore people most likely don't like
this approach. One thing that comes to mind is to allow for virtuals to
install files so we can install the provider information in a format
easy for us. We need the information in format ${PN}-${SLOT} because
that's the way we install in /usr/share. So do you think it's ok for
virtuals to install files (we can of course call the category
java-virtual/ too), should we call Portage code, or do you have an
another idea?

Regards,
Petteri
--
Gentoo/Java project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Virtuals and Java

[Vytautas Jakutis]

On Sun, 29 Apr 2007 17:00:09 +0200, Petteri Räty wrote:

> We want to implement virtuals for Java at some point and for that we
> need to know the package that provides the virtual because some virtuals
> can be provided by the JDK or normal packages and this affects the JDK
> selection at build time. One option is to call into Portage to find this
> out, but of course Paludis and Pkgcore people most likely don't like
> this approach. One thing that comes to mind is to allow for virtuals to
> install files so we can install the provider information in a format
> easy for us. We need the information in format ${PN}-${SLOT} because
> that's the way we install in /usr/share. So do you think it's ok for
> virtuals to install files (we can of course call the category
> java-virtual/ too), should we call Portage code, or do you have an
> another idea?

The virtual ebuilds that utilize JAR service provider discovery mechanism
(in META-INF/services, from jdk1.4) should install its' API jars and use
virtual/ category. And those who don't - have to be patched to utilize or
have to use some special upwards compatibility layer (generate
some special metadata file and use special eclass)..?

-- 
Vytautas Jakutis
vytautas@javy-labs.com

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Virtuals and Java

[Petteri Räty]

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

Vytautas Jakutis kirjoitti:
> On Sun, 29 Apr 2007 17:00:09 +0200, Petteri Räty wrote:
> 
>> We want to implement virtuals for Java at some point and for that we
>> need to know the package that provides the virtual because some virtuals
>> can be provided by the JDK or normal packages and this affects the JDK
>> selection at build time. One option is to call into Portage to find this
>> out, but of course Paludis and Pkgcore people most likely don't like
>> this approach. One thing that comes to mind is to allow for virtuals to
>> install files so we can install the provider information in a format
>> easy for us. We need the information in format ${PN}-${SLOT} because
>> that's the way we install in /usr/share. So do you think it's ok for
>> virtuals to install files (we can of course call the category
>> java-virtual/ too), should we call Portage code, or do you have an
>> another idea?
> 
> The virtual ebuilds that utilize JAR service provider discovery mechanism
> (in META-INF/services, from jdk1.4) should install its' API jars and use
> virtual/ category. And those who don't - have to be patched to utilize or
> have to use some special upwards compatibility layer (generate
> some special metadata file and use special eclass)..?
> 

Not really what we I am talking about. This is more ebuild related than
Java platform. For example javax.management does not use the Provider
style but it makes a good candidate for Java virtual ebuild.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Virtuals and Java

[Vytautas Jakutis]

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

So split the JRE's and JDK's into VM's, Compilers and packages like the
Ant into core and tasks, for instance:

virtual/java-vm-1.6
dev-java/sun-vm-1.6.0.2
dev-java/ibm-vm-1.4.3

virtual/java-compiler-1.6
dev-java/sun-compiler-1.6.0.2
dev-java/ibm-compiler-1.4.3

virtual/java-javax-management-1.6
dev-java/sun-javax-management-1.6
dev-java/ibm-javax-management-1.4.3

Let the commercial JDK's be forgotten if their licenses disagree with
this.

-- 
Vytautas Jakutis
vytautas@javy-labs.com

-- 
gentoo-dev@gentoo.org mailing list