Hi Martin,
If it's not too much trouble, 2, then 2b seem to be the best choices IMHO. We
take something with a friendly academic, permissive
license now, compatible with Apache SIS and ALv2, and then as we need, we
provide our own implementation as we evolve. Seems
small, and incremental enough for consensus :)
Cheers,
Chris
On Dec 1, 2012, at 8:33 AM, Martin Desruisseaux wrote:
> Hello all
>
> There is a technical problem for which the current situation is not
> satisfying, and for which I have trouble to find the best action...
>
> We needs a "Unit of measurement" framework. Because this is important to so
> many domains (even the JDK has a TimeUnit class), we made a standardisation
> attempts 12 years ago (JSR-108), which failed [1]. We made a second attempt
> (JSR-275), which failed again [2]. GeoAPI - and consequently current Apache
> SIS - currently have a dependency toward this failed JSR-275 attempt. This
> obviously brings two problems:
>
> 1) JSR-275 namespace (javax.measure.unit) is not supposed to exist.
> 2) JSR-275 bugs will never be fixed.
>
> After JSR-275 rejection, the main JSR-275 authors moved their API as
> interfaces in the "org.unitsofmeasurement.unit" package under a BSD-like
> license [3]. Those interfaces are implemented by the Eclipse UOMo project
> among others [4], and his maintainer told me that they are gaining acceptance
> in the Eclipse community.
>
> However the maintainer told me that a sensor-related JSR have good chances to
> start in 2013, could include units of measurement, and that they want to go
> fast. This would bring yet another package name in the mix (or maybe they
> would reuse the javax.measure.unit one - we don't know). So the alternatives
> at this time are:
>
> 1) Keep JSR-275 for now, wait and see.
> 2) Adopt org.unitsofmeasurement interfaces, then:
> 2a) Adopt UOMo implementation
> 2b) Provide our own implementation
> 3) Define our own interfaces
>
> On 1), we are already waiting for two years and I still have trouble to
> figure out if yes or no a third JSR attempt will happen... On 2), the problem
> is that the decision does not involve only SIS, but also GeoAPI, and as a
> standardisation attempt we are better to be as sure as possible that we will
> not change again if, for example, Oracle starts a new JSR. On 2a), I have not
> tried this UOMo implementation. But I had some trouble with the JSR-275
> implementation. Many statics methods in the Units class that I just committed
> today [5] are workarounds for JSR-275 bugs or limitations. Some methods like
> "valueOfEPSG" (scroll down until the bottom of the page) are very specific to
> the geospatial domain and unlikely to be supported natively by an external
> unit framework. The NetCDF unit names ("degrees_east", "degrees_north") are
> also quite specific, so maybe having our own implementation is not completely
> non-sense. On 2b) actually we already have an implementation from old JSR-108
> days, so it could be easily refactored to "org.unitsofmeasurement"
> interfaces. On 3), it would need to be done in GeoAPI I don't think it would
> have a lot of support...
>
> The GeoAPI working group is not active at this time, so I suspect that we may
> have more discussion on this SIS list, then brings a proposal to the GeoAPI
> list. This proposal (about interfaces only - the implementation decision stay
> on the SIS side only) would need to be written as a change request and posted
> before December 27 if we want it to be considered at the next OGC meeting.
>
> Any though, opinion, proposal would be highly appreciated...
>
> Regards,
>
> Martin
>
>
> [1] http://jcp.org/en/jsr/detail?id=108
> [2] http://jcp.org/en/jsr/detail?id=275
> [3] http://www.unitsofmeasurement.org/
> [4] http://www.eclipse.org/uomo/
> [5]
> https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/measure/Units.html
>
