Skip to main content

[jsr363-experts] Re: Possible consolidation of implementations

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: Possible consolidation of implementations
  • Date: Thu, 12 May 2016 12:04:11 +0200

Hi,

Users of UOMo who already forked it and build their solutions on Jenkins
based on the current UOMo snapshots recently joined Eclipse and filed a
proposal for a model-based Business Framework:
https://projects.eclipse.org/proposals/open-standard-business-platform-osbp

With UOMo as an integral part (I could imagine, given the right license JSR
354 could also be of interest;-) guess that makes the Eclipse path even
more appealing if it was accepted.

Regards,

Werner


On Wed, May 11, 2016 at 8:52 PM, Werner Keil 
< >
 wrote:

> Dear Experts,
>
> Based on Martin's input and speaking to Otavio and Bruno about it, the
> merge of QuantityFactoryService into ServiceProvider (to replace the getter
> of the service with that for the factory) sounds logical to everyone and
> makes the API/SPI even a bit smaller.
>
> What Otavio also suggested was a possible merge or consolidation of
> implementations we as a community or EG maintain.
>
> The obvious RI for Java ME Embedded and SE (7 and above) is out of
> question and manadatory part of the JSR.
>
> Then there are 2 other implementations or potential candidates:
>
>    - UOM-SE https://github.com/unitsofmeasurement/uom-se
>    - Eclipse UOMo in a new version: http://eclipse.org/uomo
>    - JScience 5 or 6: http://jscience.org/
>
> We agreed, I also speak with Jean-Marie about it when I should get to
> EclipseCon France next month. Especially what his plans and dedication to
> JScience.next is and if e.g. others like Otavio could help him with that.
>
> After a not very promising outlook to OpenJDK Kona or other IoT projects
> under the OpenJDK umbrella (by "people in the know" like Martijn from LJC)
> except maybe Device I/O the Eclipse option similar to Eclipse Collections
> (by Goldman Sachs) sounds appealing. Goldman rep also said he was looking
> into both JSR 363 and 354 and ways to combine them (like "Euro per Litre"
> for fuel or similar) which UOMo intended to do. And unlike the original
> approach of wrapping UOMo typesafe quantities around ICU4J, for unit
> systems like CLDR Unicode we would certainly try to use ICU, but maybe just
> in an optional "Bridge" or bundle on top of the implemention, not as a
> mandatory requirement for the Units bundle.
>
> Please think about these options and betwee now and next month, let us
> know your thoughts. Before anything can be offered or ported to Eclipse,
> first the API must be approved for Orbit by the IP team. It's demanded by
> SmartHome, so only a matter of time, but they are not "Platinum" members of
> Eclipse so it takes time, even for them.
>
> Regards,
>
> Werner
>


[jsr363-experts] Possible consolidation of implementations

Werner Keil 05/11/2016

[jsr363-experts] Re: Possible consolidation of implementations

Werner Keil 05/12/2016
 
 
Close
loading
Please Confirm
Close