Re: [osgi-dev] Correct processor types for ARM?

2020-04-13 Thread Chris Gray via osgi-dev 
Hi Peter,

I would argue that it is "os.arch" which is a bit of a mess, because it
attempts to represent too much in a single name. Compare this with the set
of "triples" here :
http://llvm.org/doxygen/classllvm_1_1Triple.html

I would argue that these definitions would be a more useful way to specify
the target for native code, as they correspond to the way that code is
compiled for the various targets.

Kind Regards

Chris


> That is my experience on the ARM processor, there are so many variations,
> 32/64, le/be, floating point/no floating point, etc. that it is a bit of a
> mess.
>
> In general, on ARM I see people define the properties themselves to
> whatever the VM they use reports.
>
> Kind regards,
>
>   Peter Kriens
>
>
>> On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev
>>  wrote:
>>
>> This has been already done by someone here:
>> https://stackoverflow.com/a/57893125
>> It seems os.arch is not really "stable" at all:
>> https://bugs.openjdk.java.net/browse/JDK-8167584
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Correct processor types for ARM?

2020-04-13 Thread Chris Gray via osgi-dev 
Hi Peter,

I would argue that it is "os.arch" which is a bit of a mess, because it
attempts to represent too much in a single name. Compare this with the set
of "triples" here :
http://llvm.org/doxygen/classllvm_1_1Triple.html

I would argue that these definitions would be a more useful way to specify
the target for native code, as they correspond to the way that code is
compiled for the various targets.

Kind Regards

Chris


> That is my experience on the ARM processor, there are so many variations,
> 32/64, le/be, floating point/no floating point, etc. that it is a bit of a
> mess.
>
> In general, on ARM I see people define the properties themselves to
> whatever the VM they use reports.
>
> Kind regards,
>
>   Peter Kriens
>
>
>> On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev
>>  wrote:
>>
>> This has been already done by someone here:
>> https://stackoverflow.com/a/57893125
>> It seems os.arch is not really "stable" at all:
>> https://bugs.openjdk.java.net/browse/JDK-8167584
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] R: Api compile-only and remote services

2018-02-08 Thread Chris Gray via osgi-dev 
In my experience it is quite often handy to have a separate API bundle -
yours is one use case, another is where the system may run on different
platforms which require different implementations for some services (cloud
vs development machine, embedded vs dev, self-contained demo vs real
distributed system, ...). In fact in a way this is the "normal"
configuration, provider-exports is a convenience.

If the packages can be exported by both api bundle and provider then you
have to watch out for "uses" constraint violations if versions diverge,
Keep It Simple is the key here.

Have fun

Chris

> I understand that with api compile only is not possible to run a remote
> instance without the related provider bundle.
>
> With a provider with conditional package I have to resolve both api and
> provider bundle because api packages are only copied inside provider but
> not exported.
> So I don’t think that is better than having api and provider separated.
>
> Now I’ve tried to modify my bundles in this way:
> - api without compile only that export packages
> - provider like before that export api packages
>
> With this configuration I can:
> - run an osgi instance resolving only provider bundle like before
> - run another instance without the provider resolving only api bundle
>
> Daniele
>
>
> Da: David Daniel
> Inviato: sabato 3 febbraio 2018 21:24
> A: Dominik Przybysz; OSGi Developer Mail List
> Cc: Daniele Pirola
> Oggetto: Re: [osgi-dev] Api compile-only and remote services
>
> I think different projects handle it differently.  The way I do it is if
> only one provider loaded will implement the interface then I include the
> interface in the provider with a conditional package and leave the api
> compile only 
> http://enroute.osgi.org/tutorial_wrap/212-conditional-package.html  If
> multiple providers are going to implement the interface then I will change
> the api bundle to a regular bundle to inclusion.
> David
>
> On Sat, Feb 3, 2018 at 2:35 PM, Dominik Przybysz via osgi-dev
>  wrote:
> Hi,
> if you know that you may run your bundles in distributed environment and
> want to use Remote Services, your API bundles must be normal bundles.
>
> 2018-02-03 19:12 GMT+01:00 Daniele Pirola via osgi-dev
> :
> Hi,
> I have an Osgi workspace with many bundles with different "types": api,
> provider and application. I follow enroute tutorials and my api bundles
> are "compile only" and providers export api packages. 
> Now I would like to use osgi remote services but how can I use api
> packages in different osgi instances without importing also the provider
> that export these packages? I have to build another api project that only
> export packages? Or api "compile only" is not the right thing for remote?
>
> Kind regards
> Daniele
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> --
> Pozdrawiam / Regards,
> Dominik Przybysz
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
Mail priva di virus. www.avg.com
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev