Skip to main content

[jsr363-experts] Re: Feature Freeze before Final Draft

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: Feature Freeze before Final Draft
  • Date: Sat, 1 Oct 2016 17:21:18 +0200

Martin,

Thanks for the update. Fortunately the "fork" of JSR-275 was done by most
of the EG, hence JSR-363 is an official successor.

I asked the Eclipse Science list and some proposed projects sounded
interested to hear how they could use JSR-363, so I should be talking to
them at the ECE Science Unconference day about usage or possible migration
from older versions. Science is somewhat related to LocationTech, but I
don't think they have an official unconference or F2F.

Regards,
Werner


On Sat, Oct 1, 2016 at 1:02 AM, Martin Desruisseaux <
>
 wrote:

> Hello Werner
>
> Le 30/09/16 à 13:33, Werner Keil a écrit :
> > Hard to say from the stats, if those download numbers come from Apache
> > SIS or Eclipse projects like uDig, some using SIS, others GeoAPI or
> > even JScience directly. If it gradually changes, that's fine.
>
> uDig, GeoTools and GeoServer uses GeoAPI, so in theory they would
> migrate. However they created their own fork of GeoAPI (without changing
> their package name) and I do not know what are their intention regarding
> unit of measurement. The usual attitude of some GeoTools developers is
> to ask money for doing anything.
>
> To make a comparison, imagine that a project forked JSR-275 and put the
> fork in their own source code repository without changing the package
> name, without consideration for the unethical aspect of using a package
> they do not own (javax.measure), without synchronization with the
> official javax.measure evolution and without consideration for the
> trouble that it cause to JSR-363 users. What uDig/GeoTools/GeoServer do
> regarding GeoAPI is similar.
>
>     Martin
>
>
>


[jsr363-experts] Re: Feature Freeze before Final Draft

Werner Keil 10/01/2016
 
 
Close
loading
Please Confirm
Close