Use Advanced Search to search the entire archive.
[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
>