Re: [oe] [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

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [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
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java] Unify virtual java providers

[Tim Orling]

On Thu, Sep 1, 2016 at 5:03 AM, Pascal Bach  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
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [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
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [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
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [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.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java] Unify virtual java providers

[Otavio Salvador]

On Tue, Aug 30, 2016 at 11:37 AM, 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.
>
> 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.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [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

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel