[meta-java] Unify virtual java providers

[meta-java] Unify virtual java providers

[Pascal Bach]

Hello


Because I'm experimenting with different java providers (OpenJDK, Oracle Java, Azul Zulu) and thus had a look at different java layers (meta-java, meta-oracle-java).

I noticed that there are many different PROVIDES statements among these recipes, but nothing seems consistent.

My proposal is thus to introduce a consistent naming for these provides so that recipes that depend on java can be written in a JRE/JDK independent way.
The naming would be the following:

- virtual/java => recipes providing a java runtime for the target (used in meta-oracle-java, replaces: java2-runtime, java2-vm)
- virtual/java-native => provide a native java runtime (exists already)
- virtual/javac => provide a jdk for the target (new, nothing like this exists, might never be used but should be defined)
- virtual/javac-native => provide a jdk for native (exists already)

It should be properly documented in the readme and the virtual packages should be the preferred way for users to depend on java/jre resp javac/jdk

An alternative to the above would be:

- virtual/jre
- virtual/jre-native
- virtual/jdk
- virtual/jdk-native

But this would deviate more from the current naming.

Any feedback on this proposal?

Pascal

Re: [meta-java] Unify virtual java providers

[Otavio Salvador]

On Tue, Aug 30, 2016 at 11:37 AM, Pascal Bach <pascal.bach@siemens.com> wrote:
> Hello
>
>
> Because I'm experimenting with different java providers (OpenJDK, Oracle Java, Azul Zulu) and thus had a look at different java layers (meta-java, meta-oracle-java).
>
> I noticed that there are many different PROVIDES statements among these recipes, but nothing seems consistent.
>
> My proposal is thus to introduce a consistent naming for these provides so that recipes that depend on java can be written in a JRE/JDK independent way.
> The naming would be the following:
>
> - virtual/java => recipes providing a java runtime for the target (used in meta-oracle-java, replaces: java2-runtime, java2-vm)
> - virtual/java-native => provide a native java runtime (exists already)
> - virtual/javac => provide a jdk for the target (new, nothing like this exists, might never be used but should be defined)
> - virtual/javac-native => provide a jdk for native (exists already)
>
> It should be properly documented in the readme and the virtual packages should be the preferred way for users to depend on java/jre resp javac/jdk
>
> An alternative to the above would be:
>
> - virtual/jre
> - virtual/jre-native
> - virtual/jdk
> - virtual/jdk-native
>
> But this would deviate more from the current naming.
>
> Any feedback on this proposal?

I prefer jre and jdk alternative; let's wait for others to comment.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-java] Unify virtual java providers

[Richard Leitner]

On 08/30/2016 04:37 PM, Pascal Bach wrote:
> Hello
> 
> 
> Because I'm experimenting with different java providers (OpenJDK, Oracle Java, Azul Zulu) and thus had a look at different java layers (meta-java, meta-oracle-java).
> 
> I noticed that there are many different PROVIDES statements among these recipes, but nothing seems consistent.
> 
> My proposal is thus to introduce a consistent naming for these provides so that recipes that depend on java can be written in a JRE/JDK independent way.

I totally agree with your proposal.

> The naming would be the following:
> 
> - virtual/java => recipes providing a java runtime for the target (used in meta-oracle-java, replaces: java2-runtime, java2-vm)
> - virtual/java-native => provide a native java runtime (exists already)
> - virtual/javac => provide a jdk for the target (new, nothing like this exists, might never be used but should be defined)
> - virtual/javac-native => provide a jdk for native (exists already)
> 
> It should be properly documented in the readme and the virtual packages should be the preferred way for users to depend on java/jre resp javac/jdk

ACK

> 
> An alternative to the above would be:
> 
> - virtual/jre
> - virtual/jre-native
> - virtual/jdk
> - virtual/jdk-native
> 
> But this would deviate more from the current naming.
> 
> Any feedback on this proposal?

Personally I would prefer the jre/jdk naming. IMHO it seems to be the
prevalent form.

Re: [meta-java] Unify virtual java providers

[Maxin B. John]

Hi,

On Tue, Aug 30, 2016 at 04:37:53PM +0200, Pascal Bach wrote:
> Hello
> 
> 
> Because I'm experimenting with different java providers (OpenJDK, Oracle Java, Azul Zulu) and thus had a look at different java layers (meta-java, meta-oracle-java).
> 
> I noticed that there are many different PROVIDES statements among these recipes, but nothing seems consistent.
> 
> My proposal is thus to introduce a consistent naming for these provides so that recipes that depend on java can be written in a JRE/JDK independent way.
> The naming would be the following:
> 
> - virtual/java => recipes providing a java runtime for the target (used in meta-oracle-java, replaces: java2-runtime, java2-vm)
> - virtual/java-native => provide a native java runtime (exists already)
> - virtual/javac => provide a jdk for the target (new, nothing like this exists, might never be used but should be defined)
> - virtual/javac-native => provide a jdk for native (exists already)
> 
> It should be properly documented in the readme and the virtual packages should be the preferred way for users to depend on java/jre resp javac/jdk
> 
> An alternative to the above would be:
> 
> - virtual/jre
> - virtual/jre-native
> - virtual/jdk
> - virtual/jdk-native
> But this would deviate more from the current naming.

+1 for the jre/jdk naming. 

> 
> Any feedback on this proposal?
> 
> Pascal

Best Regards,
Maxin

Re: [meta-java] Unify virtual java providers

[Pascal Bach]

Hi guys
> It should be properly documented in the readme and the virtual packages should be the preferred way for users to depend on java/jre resp javac/jdk
>
> An alternative to the above would be:
>
> - virtual/jre
> - virtual/jre-native
> - virtual/jdk
> - virtual/jdk-native
>
> But this would deviate more from the current naming.
>
While testing the proposal above i ran into an issue.
When I add PROVIDES = "virtual/jre" to the java recipes and i want to install multiple java versions via update-alternative I can't do that because bitbake tells me:

"Multiple .bb files are due to be built which each provide virtual/jre:"

Now the question for me is if this two mechanism are not intended to work together or if I'm doing something wrong.

My idea would be to allow the user to select a default provider for "virtual/jre" but still allow to install an additional specific java provider if necessary.
Is this even possible?

Pascal

Re: [meta-java] Unify virtual java providers

[Tim Orling]

On Thu, Sep 1, 2016 at 5:03 AM, Pascal Bach <pascal.bach@siemens.com> wrote:

> Hi guys
> > It should be properly documented in the readme and the virtual packages
> should be the preferred way for users to depend on java/jre resp javac/jdk
> >
> > An alternative to the above would be:
> >
> > - virtual/jre
> > - virtual/jre-native
> > - virtual/jdk
> > - virtual/jdk-native
> >
> > But this would deviate more from the current naming.
> >
> While testing the proposal above i ran into an issue.
> When I add PROVIDES = "virtual/jre" to the java recipes and i want to
> install multiple java versions via update-alternative I can't do that
> because bitbake tells me:
>
> "Multiple .bb files are due to be built which each provide virtual/jre:"
>
> Now the question for me is if this two mechanism are not intended to work
> together or if I'm doing something wrong.
>
>
This is a hint that you need to set PREFERRED_PROVIDER_foo in your
local.conf (or machine.conf or distro.conf or...)

http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-PREFERRED_PROVIDER

You might also need to set PREFERRED_VERSION, depending on the situation.

My idea would be to allow the user to select a default provider for
> "virtual/jre" but still allow to install an additional specific java
> provider if necessary.
> Is this even possible?
>
> Pascal
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

Re: [meta-java] Unify virtual java providers

[Pascal Bach]

>> While testing the proposal above i ran into an issue.
>> When I add PROVIDES = "virtual/jre" to the java recipes and i want to
>> install multiple java versions via update-alternative I can't do that
>> because bitbake tells me:
>>
>> "Multiple .bb files are due to be built which each provide virtual/jre:"
>>
>> Now the question for me is if this two mechanism are not intended to work
>> together or if I'm doing something wrong.
>>
>>
> This is a hint that you need to set PREFERRED_PROVIDER_foo in your
> local.conf (or machine.conf or distro.conf or...)
>
> http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-PREFERRED_PROVIDER
>
> You might also need to set PREFERRED_VERSION, depending on the situation.
>
> My idea would be to allow the user to select a default provider for
I think setting PREFERRED_VERSION is not the issue in my case.

The reason I see the issue is that I also tried to set: RPROVIDES_${PN} += "virtual/jre" in order to allow users to select "virtual/jre"
 in an RDEPENDS which I believe is necessary in many cases.

However I don't know of a way to set a preferred RPROVIDER.

>> "virtual/jre" but still allow to install an additional specific java
>> provider if necessary.
>> Is this even possible?
Based on what I found out above, don't think this is possible. Please correct me if I'm wrong.

Pascal

Re: [meta-java] Unify virtual java providers

[Pascal Bach]

>> This is a hint that you need to set PREFERRED_PROVIDER_foo in your
>> local.conf (or machine.conf or distro.conf or...)
>>
>> http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-PREFERRED_PROVIDER
>>
>> You might also need to set PREFERRED_VERSION, depending on the situation.
>>
>> My idea would be to allow the user to select a default provider for
> I think setting PREFERRED_VERSION is not the issue in my case.
>
> The reason I see the issue is that I also tried to set: RPROVIDES_${PN} += "virtual/jre" in order to allow users to select "virtual/jre"
>  in an RDEPENDS which I believe is necessary in many cases.
>
> However I don't know of a way to set a preferred RPROVIDER.
Sorry I completely missed that one can set PREFERRED_RPROVIDER too (it's not in the documentation only PREFERRED_PROVIDER is).

However when I set PREFERRED_RPROVIDER_virtual/jre = "zulu-java" i'm still not able to install zulu-java, openjdk and oracle-java at the same time.
I modified them all to RPROVIDE_${PN} += "virtual/jre" and added ALTERNATIVES for java vie updata-alternatives.
But bitbake gives me the following error:

ERROR: Nothing RPROVIDES 'oracle-java' (but /home/projects/image.bb RDEPENDS on or otherwise requires it)
ERROR: oracle-java was skipped: PREFERRED_PROVIDER_virtual/jre set to zulu-java, not oracle-java

So based on that I assume it's really not possible to have a preverd java REPROVIDER and still install others to be used via the alternatives system?

>
>>> "virtual/jre" but still allow to install an additional specific java
>>> provider if necessary.
>>> Is this even possible?
> Based on what I found out above, don't think this is possible. Please correct me if I'm wrong.
>
> Pascal