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