JSR-275 Community

[Ian Mayo]

Hi there,

I've had a great few weeks building upon the JSR-363 library.  It has proved really useful for management & conversion of units.

But, now I've come to include support for location - I've included GeoTools libraries.

Oops, that has introduced a huge (and probably predictable) problem of units-of-measurement namespaces and classes being present twice.

Unfortunately I can't drop location support - it's fundamental to my application.  So, I'm going to have to drop back to the JSR-275 library in GeoTools.   Well, at least until GeoTools one day upgrades to 363.

I'd like to contribute to the 275 branch, or at least to offer feedback/patches - should they arise.

Does 275 have a community anywhere?  Is it this community?  Or has the community left since the library got frozen (on rejection).  Aah, and is there a current source repo for JSR-275?  (the unitsofmeasurement.org domain has expired)

It's really unfortunate that I've invested so far in 363 utilisation (including all those generics).  C'est la vie.

No, it won't mean much without background context - but here's a screenshot of my progress so far:

http://i.imgur.com/N1qVeLr.png

Ian

[Werner Keil]

Hi Ian,

Thanks for the message. You scratch an itch, but mainly that of both the JCP and (more recently) Eclipse making it harder for JSR 363 to be included in places like Orbit.

There is no community for JSR-275 as the EG (for the old JSR) was dismissed when the JSR was by the EC. It officially doesn't exist.

Jean-Marie kindly registered the .org domain, and probably more official than 275 (but not under "javax." which for many alone makes a big difference, even if it's "permanent Beta") it was also accepted by Eclipse Orbit. Thanks to OSGi I see absolutely no problem if you used JSR 275 (within GeoTools) and 363 side-by side. OSGi should properly isolate them from each other and all relevant artifacts of JSR-363 (API and implementations) are OSGi bundles. 

275 wasn't which is why e.g. the company behind DAWNSci created its own "bundled" variant of JScience. Others like uDig do exactly that, since they use the JSR-275 "Pre EDR" Beta from LocationTech Orbit repo (also seems more or less signature compatible with the one in JScience 4.3) but via GeoTools automatically gets JSR-275 0.9.3 which GeoAPI 3 embeds.

So far they reported no problem, not that we'd be allowed to help them officially with 275 ;-)

I just met with Martin and we plan to apply the BSD license to all software artifacts, that should also please Eclipse. So it's up to OGC if and when they upgrade their standard, but if they do it after early 2016, there should be a Final release of JSR-363 in the first half of next year.

Also see another announcement here about Java 9 on that.

Werner

[Martin Desruisseaux]

Hello Ian

When JSR-363 will be final, it will be submitted to OGC as a replacement
for JSR-275 in GeoAPI. However GeoTools is not using the official GeoAPI
3.0 standard. It is using its own fork based on an older GeoAPI version
[1]. It would be nice to have GeoTools aligned not only on the official
javax.measure package, but also on the official GeoAPI releases. But I
think that they would need pressure from their users base in order to
move in that direction.

Alternatively you may take a look at Apache SIS (http://sis.apache.org).
It is very far from having all the functionalities of GeoTools, but it
has metadata and part of referencing modules. Apache SIS is basically a
partial port of the code that I wrote in GeoTools before I left that
project. At that time, I was the author of about 40% of GeoTools code
base. Only a fraction has been ported yet, but more are coming. During
this port, the code get a lot of cleaning and bug fixes as well as some
upgrades to new standards [2].

Apache SIS is strongly dedicated to international standards (I
participate to about two OGC meetings per year). This include compliance
of official Apache SIS releases with the official GeoAPI release. If
GeoTools users can convince GeoTools developers to do the same, it would
be possible for you and other users to combine Apache SIS and GeoTools
in your application, if you find useful to complete one library with the
other. Alternatively GeoTools could replace its own metadata and
referencing modules by a dependency to Apache SIS, since I think that
most of the development is happening there for those particular modules.


Regards,

Martin


[1] http://osgeo-org.1560.x6.nabble.com/Unethical-use-of-GeoAPI-library-in-Geotools-td5188705.html
[2] http://events.linuxfoundation.org/sites/events/files/slides/RecentEvolutionInGeospatialStandard.pdf

[Ian Mayo]

Hi there Martin,

thanks for your reply.  I knew I recognised your name from somewhere :-)

Limpet is going to feature as a plug-in to an existing application (www.debrief.info).  Debrief already makes extensive use of GeoTools, so it's not sensible for me to adopt an alternate spatial/metadata library.

In support of that, I look forward to the time when the GeoTools community receive sufficient funding to "merge back into the trunk" of these mature standards.

Regards,

Ian

[Ian Mayo]

Werner,

that all sounds nice and optimistic.  Sadly I can't isolate 275 & 363 via OSGI - since I need to use GeoTools Geometry objects and UoM Quantities not only in the same plugin, but in the same class.

In moving to 275 I've lost a few capabilities, but unit tests have allowed me to confidently change the underlying UoM library.

I look forward to my upstream dependencies moving to 363 - and hopefully I can contribute to the development of 363.  For now I'll have to accept that I'm locked into this frozen version.

cheers,

Ian

[Werner Keil]

Ian,

Thanks for the reply. Seems while OSGi in theory promises to isolate modules from each other, at least when you directly interact with say a Unit type or some GeoAPI element that is backed by JSR 275 types you may indeed run into conflicts.

It's rather fuzzy where JSR 275 is made available by Eclipse Orbit (seems not the main orbit, but one for LocationTech) but most major Eclipse projects directly at eclipse.org (aside from UOMo which switched to Unit-API 0.6) for the time being have to use the frozen, "as is" JSR 275.

We plan to go Public Draft with 363 right after JavaOne and a new license document scheme (based on e.g. the likes of JSR 375) should allow Eclipse Foundation or others to use 363 without problems. If you rely on GeoAPI, you'd have to wait till its version 4 or 3.x is released based on JSR 363.

We're happy to help with the transition whenever you may face it.

Cheers,

Werner

[Werner Keil]

Ian,

Nice meeting you at Eclipse Science Unconference the other week.

This may not be so relevant any more, but as part of the Kenai.com/java.net ramp-down I moved the sources of JSR 275 to GitHub a while ago and requested the kenai.com "tarball" Oracle is offering to archive it.
As a forward address after they shut down Kenai.com I chose http://unitsofmeasurement.github.io/jsr-275. It's a very basic GitHub page, but e.g. "Download Tarball" in addition to the GitHub sources could allow access to the Oracle-generated Tarball of the old Kenai project. That is all we feel appropriate for JSR 275. Since it is still downloaded a lot (getting close to 100k downloads within a year: https://bintray.com/keilw/maven/javax.measure%3Ajsr-275#statistics) we think we have the responsibility to keep the sources and everything we get from Kenai/Oracle archived, but there's no support especially after JSR 363 is final now.

Regards,
Werner