Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

Hi Eric

Open discussion:

*>>- The idea is to create a temporary Git project/repository as Ede
mentioned too. There are two main platforms for that, GitHub and GitLab.
Let me know which one you prefer, knowing that it is possible to have both
solutions, working only on one, with a mirroring for the other using this
solution (this includes automated
push/pull): 
https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html
*

No preference for me. As I can see GitLab offers a free Continuous
Integration which could be useful in a project like Openjump where Night
builds are very frequent and, sometime,  preferred by users more than the
stable realize.

*>>Would you prefer an open or a private repository? Why do I consider the
private option here? To avoid any confusion with the current OpenJUMP
repository on sourceforge and to avoid some possible premature forks,*

I am not afraid if forks: it is a part of the surviving life of Jump. Right
now Openjump is the only (as far as I know) survivor of Jump family. Anyhow
I agree to a private repository only for the time of migration. And to make
it public when we are sure that everything is working.

- >>*Where do I need to create this project? In my personal account, or an
OpenJUMP organisation is created, and the project takes place there (I
would personally prefer this option, in link with my preliminary remark)?
If an OpenJUMP organisation is created, do you want to create it yourself
or is it OK if I create it?*

Openjump organization seems in continuity with the "philosophy" of the
project.

- >>*Have you already got some GitHub/GitLab accounts that I could use to
let you access the project as administrators?*

Not yet. I will open one in these days

Peppe


Il mar 11 ago 2020, 23:59 Eric  ha scritto:

> Hi Ede,
>
> Thanks. I let the licencing issue aside as it seems to be resolved. See
> my inline answers.
>
> On 11/08/2020 12:01, edgar.sol...@web.de wrote:
> > tl;dr let's wait how the licensing issue (other email) turns out, apart
> from that my answers below.
> >
> > On 10.08.2020 15:42, Eric wrote:
> >> Hi Ede,
> >>
> >> Thanks for your welcome and for your answers. See my inline replies for
> some of them (I deleted the other parts).
> >>
> >> On 09/08/2020 16:40, edgar.sol...@web.de wrote:
> >>> hey Eric,
> >>>
> >>> welcome to the team! see my answers below
> >>>
> >>> On 07.08.2020 20:55, Eric wrote:
>  Then I checked which OJ lib dependencies rely on JTS and it seems
> that there is only deegree 2,
>  without considering here the plethora of extensions/plugins.
> >>> which is the main obstacle. the only clean solution i see is to branch
> out a new OJ 2.x that initially will break compatibility to all external
> plugins. that's the bad news.
> >>> the good news is that this forces us to retouch pretty much all of
> them and during this effort we might eventually come up with a working
> plugin manager after all.
> >> Less than a day of work should be required (if not less) to update all
> the plugins which do not rely on a dependency which relies itself on JTS.
> I'm going to test it, to see if it's the case.
> >> I tried with my plugins and I just needed a couple of seconds to do it.
> > again. we don't have sources for all extensions in OJ Plus at hand or
> setup to build at all. the challenge won't be the modding but the finding
> and setting up plugin repos.
>
> I wasn't aware of this situation. All of a sudden, it seems to be
> another challenge to migrate all the plugins...
>
>  This is quite a good news because
>  if the deegree dependency is updated to its latest version (3.x.x),
> which relies on JTS 1.15,
>  then, theoretically, only the import statements and a few other
> com.vividsolutions directly used in the code
>  need to be modified.
> >>> yeah, probably not. deegree2 is afaics used primarily or exclusively
> for the WFS extension and i remember checking out deegree3 as a drop in for
> deegree2 but failing miserably. that's why i stuck with deegree2 happy to
> have at least a working WFS extension for the time being.
> >>>
> >>> but again, we can remove WFS from core for OJ 2.x and come up with a
> working extension later (if at all).
> >> It seems to be a good compromise for the time being as the migration
> from deegree-core 2 to deegree-core 3 isn't straightforward.
> > agreed
>
> So I'll do that.
>
>  - the GeoJSON part (com.vividsolutions.jump.io.geojson) is
> problematic due to the jts-io
>  pom type only, but once imported, this part of the code will be
> functional again,
> >>> how do you figure? com.vividsolutions.jump.io.geojson was written by
> myself from scratch utilizing google's json-simple . it holds no dependency
> apart from the jts geometry code. maybe myself placing it in this package
> has mislead you
> >> Have a look at the GeoJsonReader class for example, and the method
> 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Eric]

Hi Ede,

Thanks. I let the licencing issue aside as it seems to be resolved. See 
my inline answers.


On 11/08/2020 12:01, edgar.sol...@web.de wrote:

tl;dr let's wait how the licensing issue (other email) turns out, apart from 
that my answers below.

On 10.08.2020 15:42, Eric wrote:

Hi Ede,

Thanks for your welcome and for your answers. See my inline replies for some of 
them (I deleted the other parts).

On 09/08/2020 16:40, edgar.sol...@web.de wrote:

hey Eric,

welcome to the team! see my answers below

On 07.08.2020 20:55, Eric wrote:

Then I checked which OJ lib dependencies rely on JTS and it seems that there is 
only deegree 2,
without considering here the plethora of extensions/plugins.

which is the main obstacle. the only clean solution i see is to branch out a 
new OJ 2.x that initially will break compatibility to all external plugins. 
that's the bad news.
the good news is that this forces us to retouch pretty much all of them and 
during this effort we might eventually come up with a working plugin manager 
after all.

Less than a day of work should be required (if not less) to update all the 
plugins which do not rely on a dependency which relies itself on JTS. I'm going 
to test it, to see if it's the case.
I tried with my plugins and I just needed a couple of seconds to do it.

again. we don't have sources for all extensions in OJ Plus at hand or setup to 
build at all. the challenge won't be the modding but the finding and setting up 
plugin repos.


I wasn't aware of this situation. All of a sudden, it seems to be 
another challenge to migrate all the plugins...



This is quite a good news because
if the deegree dependency is updated to its latest version (3.x.x), which 
relies on JTS 1.15,
then, theoretically, only the import statements and a few other 
com.vividsolutions directly used in the code
need to be modified.

yeah, probably not. deegree2 is afaics used primarily or exclusively for the 
WFS extension and i remember checking out deegree3 as a drop in for deegree2 
but failing miserably. that's why i stuck with deegree2 happy to have at least 
a working WFS extension for the time being.

but again, we can remove WFS from core for OJ 2.x and come up with a working 
extension later (if at all).

It seems to be a good compromise for the time being as the migration from 
deegree-core 2 to deegree-core 3 isn't straightforward.

agreed


So I'll do that.


- the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic due to 
the jts-io
pom type only, but once imported, this part of the code will be functional 
again,

how do you figure? com.vividsolutions.jump.io.geojson was written by myself 
from scratch utilizing google's json-simple . it holds no dependency apart from 
the jts geometry code. maybe myself placing it in this package has mislead you

Have a look at the GeoJsonReader class for example, and the method 
MapGeoJsonGeometryReader (see the comment), or the 
GeoJSONFeatureCollectionWrapper class. You will see that there is a dependency 
to JTS io.
It doesn't mean that there is a real dependency in the way it works, but JTS io 
(now jts-io-common which includes the GeoJSON code) is needed for the code to 
compile.

good catch ;). right for creating Geoms from Maps JTS is used. forgot about it.

depending on the size of the import we might just copy the code from the latest 
LGPL'd JTS or actually implement it ourselfs. ok, just checked
   https://github.com/locationtech/jts/releases/tag/1.17.0
jts-io-common-1.17.0.jar is just 15kB big so let's just keep the JTS code.


OK.


- some classes have been deprecated, removed, or simply moved in the new JTS 
versions,
such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory. New 
interfaces
have been created in JTS. It shouldn't be too complex to find a solution or a 
workaround,

agreed

After the JTS upgrade, only two classes require some changes:
- org.openjump.core.ui.plugin.tools.ReducePointsISAPlugIn -- relatively easy to 
solve,
- another written by Michaël, com.vividsolutions.jump.geom.MakeValidOp. For 
this one, a few JTS constructors have evolved. The problem is linked to the 4th 
dimension, dimension that can't be retrieved any more with a simple getter. One 
temporary solution could consist in the creation of a class which extends the 
current JTS one with an additional getter / setter for the dimension.

sounds reasonable


I'll then use this temporary solution.


Once these problems of imports are solved, the JTS update should be relatively
straightforward, and some work will probably be needed to update the code
based on deegree. I tried to update one of my plugins, it took me seconds
to do it, and I know that it would be exactly the same for the others, just by
replacing com.vividsolutions.jts by org.locationtech.jts.

sure. problem is not the port but gathering all plugin sources, setting up 
build env, porting and releasing the new modification for each and everyone. on 
the other hand, 

Re: [JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

[edgar . soldin]

Jody, understood. thanks for clearing that up!

what's the advantage of the EPL2 then if you are essentially also licensed 
BSD-style? or asked differently why would anyone use the EPL when you can 
license the product without any restriction whatsoever as well?

..ede

On 11.08.2020 16:06, Jody Garnett wrote:
> This is why we took the opportunity to dual license JTS when we had the
> chance. I am happy to update the FAQ with a GPL+BSD example.
>
> On Tue, Aug 11, 2020 at 7:04 AM  wrote:
>
>> looks like the geoserver folks added an exception for EPL and others to
>> their GPL2.
>> https://docs.geoserver.org/stable/en/user/introduction/license.html
>>
>> unfortunately we cannot relicense our sources as we cannot get the ok from
>> _all_ developers/companies having laid hands on it over time. but even if
>> we could, i understand that adding exceptions to the GPL makes your
>> software itself incompatible with plainly GPL licensed products. not sure
>> how the geoserver people solved that issue.
>>
>> so just to sum up: EDL is a BSD-style license that can be pretty much
>> paired with anything, so being GPL'd we will use JTS under EDL. right?
>>
>> ..ede
>>
>> On 11.08.2020 15:53, Jody Garnett wrote:
>>> You two have reproduced our thinking exactly. Check out the GeoServer
>>> license for another approach also.
>>>
>>> On Tue, Aug 11, 2020 at 4:08 AM  wrote:
>>>
 Eric, sounds plausible.

 Jody. maybe you can add GPL'd software as another example in
 https://github.com/locationtech/jts/blob/master/FAQ-LICENSING.md ?

 thanks.. ede

 On 11.08.2020 12:58, Eric wrote:
> Hi again,
>
> "The Eclipse Distribution License is an OSI Approved Open Source
>> License
 by means of the New BSD License <
 http://www.opensource.org/licenses/BSD-3-Clause>".
> Source: https://www.eclipse.org/org/documents/edl-v10.php
>
> The New BSD License refers to a 3-Clause BSD License.
> Source: https://opensource.org/licenses/BSD-3-Clause
>
> GPL and 3-Clause BSD License are compatible according to FSF:
>

>> https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_(%22BSD_License_2.0%22,_%22Revised_BSD_License%22,_%22New_BSD_License%22,_or_%22Modified_BSD_License%22)
>
> So if the EDL is used, there is no incompatibility.
>
> Jody, could you please confirm this.
>
> Eric
>
> On 11/08/2020 11:47, Eric wrote:
>> Hi,
>>
>> JTS is dual-licensed under:
>> - Eclipse Public License 2.0
>> - Eclipse Distribution License 1.0 (a BSD Style License)
>>
>> This second licence, if BSD style, should normally be compatible with
 the GPL one.
>>
>> Eric
>>
>> On 11/08/2020 11:28, edgar.sol...@web.de wrote:
>>> hey All,
>>>
>>> just noticed that locationtech relicensed JTS to EPL2, which as far
>> as
 i read it is incompatible to the GPL (any version).
 https://www.eclipse.org/legal/epl-2.0/faq.php#h.mz8pxljvc07w
>>> the mentioned "Exhibit A — Form of Secondary Licenses Notice" seems
>> to
 be empty in JTS' version of the license
>>> https://github.com/locationtech/jts/blob/master/LICENSE_EPLv2.txt
>>> note we are not allowed to relicense JUMP code to something other
>> than
 a later GPL version.
>>>
>>> Geotools being LGPL'd seems to be compatible, so they didn't run into
 problems here
>>>https://www.eclipse.org/legal/epl-2.0/faq.php#h.hsnsfg4e0htq
>>>
>>> i'll CC Jody, maybe he can shed some light.
>>>
>>> ..ede
>>>
>>>
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

 --
>>> --
>>> Jody Garnett
>>>
>>
>> --
> --
> Jody Garnett
>



___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

[edgar . soldin]

looks like the geoserver folks added an exception for EPL and others to their 
GPL2.
https://docs.geoserver.org/stable/en/user/introduction/license.html

unfortunately we cannot relicense our sources as we cannot get the ok from 
_all_ developers/companies having laid hands on it over time. but even if we 
could, i understand that adding exceptions to the GPL makes your software 
itself incompatible with plainly GPL licensed products. not sure how the 
geoserver people solved that issue.

so just to sum up: EDL is a BSD-style license that can be pretty much paired 
with anything, so being GPL'd we will use JTS under EDL. right?

..ede

On 11.08.2020 15:53, Jody Garnett wrote:
> You two have reproduced our thinking exactly. Check out the GeoServer
> license for another approach also.
>
> On Tue, Aug 11, 2020 at 4:08 AM  wrote:
>
>> Eric, sounds plausible.
>>
>> Jody. maybe you can add GPL'd software as another example in
>> https://github.com/locationtech/jts/blob/master/FAQ-LICENSING.md ?
>>
>> thanks.. ede
>>
>> On 11.08.2020 12:58, Eric wrote:
>>> Hi again,
>>>
>>> "The Eclipse Distribution License is an OSI Approved Open Source License
>> by means of the New BSD License <
>> http://www.opensource.org/licenses/BSD-3-Clause>".
>>> Source: https://www.eclipse.org/org/documents/edl-v10.php
>>>
>>> The New BSD License refers to a 3-Clause BSD License.
>>> Source: https://opensource.org/licenses/BSD-3-Clause
>>>
>>> GPL and 3-Clause BSD License are compatible according to FSF:
>>>
>> https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_(%22BSD_License_2.0%22,_%22Revised_BSD_License%22,_%22New_BSD_License%22,_or_%22Modified_BSD_License%22)
>>>
>>> So if the EDL is used, there is no incompatibility.
>>>
>>> Jody, could you please confirm this.
>>>
>>> Eric
>>>
>>> On 11/08/2020 11:47, Eric wrote:
 Hi,

 JTS is dual-licensed under:
 - Eclipse Public License 2.0
 - Eclipse Distribution License 1.0 (a BSD Style License)

 This second licence, if BSD style, should normally be compatible with
>> the GPL one.

 Eric

 On 11/08/2020 11:28, edgar.sol...@web.de wrote:
> hey All,
>
> just noticed that locationtech relicensed JTS to EPL2, which as far as
>> i read it is incompatible to the GPL (any version).
>> https://www.eclipse.org/legal/epl-2.0/faq.php#h.mz8pxljvc07w
> the mentioned "Exhibit A — Form of Secondary Licenses Notice" seems to
>> be empty in JTS' version of the license
> https://github.com/locationtech/jts/blob/master/LICENSE_EPLv2.txt
> note we are not allowed to relicense JUMP code to something other than
>> a later GPL version.
>
> Geotools being LGPL'd seems to be compatible, so they didn't run into
>> problems here
>https://www.eclipse.org/legal/epl-2.0/faq.php#h.hsnsfg4e0htq
>
> i'll CC Jody, maybe he can shed some light.
>
> ..ede
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

>>>
>>>
>>>
>>>
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>
>> --
> --
> Jody Garnett
>



___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

[edgar . soldin]

Eric, sounds plausible.

Jody. maybe you can add GPL'd software as another example in 
https://github.com/locationtech/jts/blob/master/FAQ-LICENSING.md ?

thanks.. ede

On 11.08.2020 12:58, Eric wrote:
> Hi again,
>
> "The Eclipse Distribution License is an OSI Approved Open Source License by 
> means of the New BSD License 
> ".
> Source: https://www.eclipse.org/org/documents/edl-v10.php
>
> The New BSD License refers to a 3-Clause BSD License.
> Source: https://opensource.org/licenses/BSD-3-Clause
>
> GPL and 3-Clause BSD License are compatible according to FSF:
> https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_(%22BSD_License_2.0%22,_%22Revised_BSD_License%22,_%22New_BSD_License%22,_or_%22Modified_BSD_License%22)
>
> So if the EDL is used, there is no incompatibility.
>
> Jody, could you please confirm this.
>
> Eric
>
> On 11/08/2020 11:47, Eric wrote:
>> Hi,
>>
>> JTS is dual-licensed under:
>> - Eclipse Public License 2.0
>> - Eclipse Distribution License 1.0 (a BSD Style License)
>>
>> This second licence, if BSD style, should normally be compatible with the 
>> GPL one.
>>
>> Eric
>>
>> On 11/08/2020 11:28, edgar.sol...@web.de wrote:
>>> hey All,
>>>
>>> just noticed that locationtech relicensed JTS to EPL2, which as far as i 
>>> read it is incompatible to the GPL (any version). 
>>> https://www.eclipse.org/legal/epl-2.0/faq.php#h.mz8pxljvc07w
>>> the mentioned "Exhibit A — Form of Secondary Licenses Notice" seems to be 
>>> empty in JTS' version of the license
>>> https://github.com/locationtech/jts/blob/master/LICENSE_EPLv2.txt
>>> note we are not allowed to relicense JUMP code to something other than a 
>>> later GPL version.
>>>
>>> Geotools being LGPL'd seems to be compatible, so they didn't run into 
>>> problems here
>>>    https://www.eclipse.org/legal/epl-2.0/faq.php#h.hsnsfg4e0htq
>>>
>>> i'll CC Jody, maybe he can shed some light.
>>>
>>> ..ede
>>>
>>>
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>



___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[edgar . soldin]

tl;dr let's wait how the licensing issue (other email) turns out, apart from 
that my answers below.

On 10.08.2020 15:42, Eric wrote:
> Hi Ede,
>
> Thanks for your welcome and for your answers. See my inline replies for some 
> of them (I deleted the other parts).
>
> On 09/08/2020 16:40, edgar.sol...@web.de wrote:
>> hey Eric,
>>
>> welcome to the team! see my answers below
>>
>> On 07.08.2020 20:55, Eric wrote:
>>> Then I checked which OJ lib dependencies rely on JTS and it seems that 
>>> there is only deegree 2,
>>> without considering here the plethora of extensions/plugins.
>> which is the main obstacle. the only clean solution i see is to branch out a 
>> new OJ 2.x that initially will break compatibility to all external plugins. 
>> that's the bad news.
>> the good news is that this forces us to retouch pretty much all of them and 
>> during this effort we might eventually come up with a working plugin manager 
>> after all.
>
> Less than a day of work should be required (if not less) to update all the 
> plugins which do not rely on a dependency which relies itself on JTS. I'm 
> going to test it, to see if it's the case.
> I tried with my plugins and I just needed a couple of seconds to do it.

again. we don't have sources for all extensions in OJ Plus at hand or setup to 
build at all. the challenge won't be the modding but the finding and setting up 
plugin repos.

>>> This is quite a good news because
>>> if the deegree dependency is updated to its latest version (3.x.x), which 
>>> relies on JTS 1.15,
>>> then, theoretically, only the import statements and a few other 
>>> com.vividsolutions directly used in the code
>>> need to be modified.
>> yeah, probably not. deegree2 is afaics used primarily or exclusively for the 
>> WFS extension and i remember checking out deegree3 as a drop in for deegree2 
>> but failing miserably. that's why i stuck with deegree2 happy to have at 
>> least a working WFS extension for the time being.
>>
>> but again, we can remove WFS from core for OJ 2.x and come up with a working 
>> extension later (if at all).
>
> It seems to be a good compromise for the time being as the migration from 
> deegree-core 2 to deegree-core 3 isn't straightforward.

agreed

>>> - the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic due 
>>> to the jts-io
>>> pom type only, but once imported, this part of the code will be functional 
>>> again,
>> how do you figure? com.vividsolutions.jump.io.geojson was written by myself 
>> from scratch utilizing google's json-simple . it holds no dependency apart 
>> from the jts geometry code. maybe myself placing it in this package has 
>> mislead you
>
> Have a look at the GeoJsonReader class for example, and the method 
> MapGeoJsonGeometryReader (see the comment), or the 
> GeoJSONFeatureCollectionWrapper class. You will see that there is a 
> dependency to JTS io.
> It doesn't mean that there is a real dependency in the way it works, but JTS 
> io (now jts-io-common which includes the GeoJSON code) is needed for the code 
> to compile.

good catch ;). right for creating Geoms from Maps JTS is used. forgot about it.

depending on the size of the import we might just copy the code from the latest 
LGPL'd JTS or actually implement it ourselfs. ok, just checked
  https://github.com/locationtech/jts/releases/tag/1.17.0
jts-io-common-1.17.0.jar is just 15kB big so let's just keep the JTS code.

>>> - some classes have been deprecated, removed, or simply moved in the new 
>>> JTS versions,
>>> such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory. New 
>>> interfaces
>>> have been created in JTS. It shouldn't be too complex to find a solution or 
>>> a workaround,
>> agreed
>
> After the JTS upgrade, only two classes require some changes:
> - org.openjump.core.ui.plugin.tools.ReducePointsISAPlugIn -- relatively easy 
> to solve,
> - another written by Michaël, com.vividsolutions.jump.geom.MakeValidOp. For 
> this one, a few JTS constructors have evolved. The problem is linked to the 
> 4th dimension, dimension that can't be retrieved any more with a simple 
> getter. One temporary solution could consist in the creation of a class which 
> extends the current JTS one with an additional getter / setter for the 
> dimension.

sounds reasonable

>>> Once these problems of imports are solved, the JTS update should be 
>>> relatively
>>> straightforward, and some work will probably be needed to update the code
>>> based on deegree. I tried to update one of my plugins, it took me seconds
>>> to do it, and I know that it would be exactly the same for the others, just 
>>> by
>>> replacing com.vividsolutions.jts by org.locationtech.jts.
>> sure. problem is not the port but gathering all plugin sources, setting up 
>> build env, porting and releasing the new modification for each and everyone. 
>> on the other hand, there is no alternative since locationtech forced our hand
> I answer this point later in the discussion, 

Re: [JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

[Eric]

Hi again,

"The Eclipse Distribution License is an OSI Approved Open Source License 
by means of the New BSD License 
".

Source: https://www.eclipse.org/org/documents/edl-v10.php

The New BSD License refers to a 3-Clause BSD License.
Source: https://opensource.org/licenses/BSD-3-Clause

GPL and 3-Clause BSD License are compatible according to FSF:
https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_(%22BSD_License_2.0%22,_%22Revised_BSD_License%22,_%22New_BSD_License%22,_or_%22Modified_BSD_License%22)

So if the EDL is used, there is no incompatibility.

Jody, could you please confirm this.

Eric

On 11/08/2020 11:47, Eric wrote:

Hi,

JTS is dual-licensed under:
- Eclipse Public License 2.0
- Eclipse Distribution License 1.0 (a BSD Style License)

This second licence, if BSD style, should normally be compatible with 
the GPL one.


Eric

On 11/08/2020 11:28, edgar.sol...@web.de wrote:

hey All,

just noticed that locationtech relicensed JTS to EPL2, which as far 
as i read it is incompatible to the GPL (any version). 
https://www.eclipse.org/legal/epl-2.0/faq.php#h.mz8pxljvc07w
the mentioned "Exhibit A — Form of Secondary Licenses Notice" seems 
to be empty in JTS' version of the license

https://github.com/locationtech/jts/blob/master/LICENSE_EPLv2.txt
note we are not allowed to relicense JUMP code to something other 
than a later GPL version.


Geotools being LGPL'd seems to be compatible, so they didn't run into 
problems here

   https://www.eclipse.org/legal/epl-2.0/faq.php#h.hsnsfg4e0htq

i'll CC Jody, maybe he can shed some light.

..ede


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel




___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #496 OpenJUMP 1.15 freezes on loading project files from differing versions

[Giuseppe Aruta]

Thanks Ede, you were faster ;-)

> [bugs:#496] OpenJUMP 1.15 freezes on loading project files from differing 
> versions Status: open Created: Tue Aug 11, 2020 10:35 AM UTC by ede Last 
> Updated: Tue Aug 11, 2020 10:35 AM UTC Owner: nobody as described by Peppe on 
> the mailing list " On loading project files saved with different versions of 
> OpenJUMP. There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on 
> saving/loading project files. a) OpenJUMP 1.5 freezes on loading project 
> files saved at least with OpenJUMP 6363 and 6370 The console (I use Linux) 
> doesn't show any warning. b) OpenJUMP 6363 and 6370 cannot load project files 
> saved at least with OpenJUMP 1.5 . The console doesn't show any warning. c) 
> OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice versa 
> " Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
> subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from 
> further messages, a project admin can change settings at 
> https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a 
> mailing list, you can unsubscribe from the mailing list. 
> ___ Jump-pilot-devel mailing list 
> Jump-pilot-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

[Eric]

Hi,

JTS is dual-licensed under:
- Eclipse Public License 2.0
- Eclipse Distribution License 1.0 (a BSD Style License)

This second licence, if BSD style, should normally be compatible with 
the GPL one.


Eric

On 11/08/2020 11:28, edgar.sol...@web.de wrote:

hey All,

just noticed that locationtech relicensed JTS to EPL2, which as far as i read 
it is incompatible to the GPL (any version). 
https://www.eclipse.org/legal/epl-2.0/faq.php#h.mz8pxljvc07w
the mentioned "Exhibit A — Form of Secondary Licenses Notice" seems to be empty 
in JTS' version of the license
   https://github.com/locationtech/jts/blob/master/LICENSE_EPLv2.txt
note we are not allowed to relicense JUMP code to something other than a later 
GPL version.

Geotools being LGPL'd seems to be compatible, so they didn't run into problems 
here
   https://www.eclipse.org/legal/epl-2.0/faq.php#h.hsnsfg4e0htq

i'll CC Jody, maybe he can shed some light.

..ede


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel




___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [jump-pilot:bugs] #496 OpenJUMP 1.15 freezes on loading project files from differing versions

[ede via Jump-pilot-devel]

---

** [bugs:#496] OpenJUMP 1.15 freezes on loading project files from differing 
versions**

**Status:** open
**Created:** Tue Aug 11, 2020 10:35 AM UTC by ede
**Last Updated:** Tue Aug 11, 2020 10:35 AM UTC
**Owner:** nobody


as described by Peppe on the mailing list
"
*On loading project files saved with different versions of OpenJUMP*.
There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
saving/loading project files.
   a) OpenJUMP 1.5 freezes on loading project files saved at least with
OpenJUMP 6363 and 6370
  The console (I use Linux) doesn't show any warning.
   b) OpenJUMP 6363 and 6370  cannot load project files saved at least with
OpenJUMP 1.5 .
The console doesn't show any warning.
  c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice
versa
"


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

[edgar . soldin]

hey All,

just noticed that locationtech relicensed JTS to EPL2, which as far as i read 
it is incompatible to the GPL (any version). 
https://www.eclipse.org/legal/epl-2.0/faq.php#h.mz8pxljvc07w
the mentioned "Exhibit A — Form of Secondary Licenses Notice" seems to be empty 
in JTS' version of the license
  https://github.com/locationtech/jts/blob/master/LICENSE_EPLv2.txt
note we are not allowed to relicense JUMP code to something other than a later 
GPL version.

Geotools being LGPL'd seems to be compatible, so they didn't run into problems 
here
  https://www.eclipse.org/legal/epl-2.0/faq.php#h.hsnsfg4e0htq

i'll CC Jody, maybe he can shed some light.

..ede


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Git Repo ids Was:Re: OJ 2.x Was:Re: JTS update: first experiments

[edgar . soldin]

Eric,

surely we can use whatever we decide as "email" as long as it fit's the syntax 
or? as all of these are sf.net users we could simply use the 
@users.sourceforge.net .

..ede

On 11.08.2020 11:50, Eric wrote:
> The problem is that email addresses are required to be able to keep the 
> authors.
>
> A solution could be to use the email addresses for the active developers and 
> to use another generic email address for all the others (this one could be 
> one created for this sole purpose using gmail). This would technically work.
>
> Eric
>
> On 11/08/2020 10:29, edgar.sol...@web.de wrote:
>> working mail addresses will be difficult to get for everyine and generally 
>> unnecessary as well. just need to keep the history and committer ids to 
>> enable retracing changes in the future as well.
>>
>> ..ede
>>
>> On 10.08.2020 15:52, Eric wrote:
>>> Here is the list of all the SVN authors (and their number of contributions) 
>>> according to the logs:
>>> beckerl 197
>>> bertazza 29
>>> bgudehus 6
>>> clark 6
>>> edso 1305
>>> elnico 54
>>> eric.lemesre 4
>>> infinityedge 2
>>> jammerhund 47
>>> javamap 10
>>> jratike80 22
>>> kdneufeld 2
>>> lreeder 1
>>> ma15569 602
>>> mentaer 465
>>> michaudm 1619
>>> paul_d_austin 38
>>> s-l-teichmann 1
>>> stranger 87
>>>
>>> If you want to keep track of them in the possible future Git repository, a 
>>> conversion file needs to be created, for example (with one author per line):
>>> michaudm = Michael Michaud 
>>>
>>> We should maybe do this outside this mailing list to avoid creating a list 
>>> of public email addresses.
>>>
>>> For info, I easily managed to locally create a Git repository containing 
>>> the 1.15 release of OpenJUMP, using the 6242 revision. I'm waiting for your 
>>> different answers to move to the next step.
>>>
>>> Best,
>>> Eric
>>>
>>> On 10/08/2020 14:42, Eric wrote:
 Hi Ede,

 Thanks for your welcome and for your answers. See my inline replies for 
 some of them (I deleted the other parts).

 On 09/08/2020 16:40, edgar.sol...@web.de wrote:
> hey Eric,
>
> welcome to the team! see my answers below
>
> On 07.08.2020 20:55, Eric wrote:
>> Then I checked which OJ lib dependencies rely on JTS and it seems that 
>> there is only deegree 2,
>> without considering here the plethora of extensions/plugins.
> which is the main obstacle. the only clean solution i see is to branch 
> out a new OJ 2.x that initially will break compatibility to all external 
> plugins. that's the bad news.
> the good news is that this forces us to retouch pretty much all of them 
> and during this effort we might eventually come up with a working plugin 
> manager after all.
 Less than a day of work should be required (if not less) to update all the 
 plugins which do not rely on a dependency which relies itself on JTS. I'm 
 going to test it, to see if it's the case.
 I tried with my plugins and I just needed a couple of seconds to do it.

>> This is quite a good news because
>> if the deegree dependency is updated to its latest version (3.x.x), 
>> which relies on JTS 1.15,
>> then, theoretically, only the import statements and a few other 
>> com.vividsolutions directly used in the code
>> need to be modified.
> yeah, probably not. deegree2 is afaics used primarily or exclusively for 
> the WFS extension and i remember checking out deegree3 as a drop in for 
> deegree2 but failing miserably. that's why i stuck with deegree2 happy to 
> have at least a working WFS extension for the time being.
>
> but again, we can remove WFS from core for OJ 2.x and come up with a 
> working extension later (if at all).
 It seems to be a good compromise for the time being as the migration from 
 deegree-core 2 to deegree-core 3 isn't straightforward.

>> - the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic 
>> due to the jts-io
>> pom type only, but once imported, this part of the code will be 
>> functional again,
> how do you figure? com.vividsolutions.jump.io.geojson was written by 
> myself from scratch utilizing google's json-simple . it holds no 
> dependency apart from the jts geometry code. maybe myself placing it in 
> this package has mislead you
 Have a look at the GeoJsonReader class for example, and the method 
 MapGeoJsonGeometryReader (see the comment), or the 
 GeoJSONFeatureCollectionWrapper class. You will see that there is a 
 dependency to JTS io.
 It doesn't mean that there is a real dependency in the way it works, but 
 JTS io (now jts-io-common which includes the GeoJSON code) is needed for 
 the code to compile.

>> - some classes have been deprecated, removed, or simply moved in the new 
>> JTS versions,
>> such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory. 
>> New interfaces

Re: [JPP-Devel] Git Repo ids Was:Re: OJ 2.x Was:Re: JTS update: first experiments

[Eric]

The problem is that email addresses are required to be able to keep the 
authors.


A solution could be to use the email addresses for the active developers 
and to use another generic email address for all the others (this one 
could be one created for this sole purpose using gmail). This would 
technically work.


Eric

On 11/08/2020 10:29, edgar.sol...@web.de wrote:

working mail addresses will be difficult to get for everyine and generally 
unnecessary as well. just need to keep the history and committer ids to enable 
retracing changes in the future as well.

..ede

On 10.08.2020 15:52, Eric wrote:

Here is the list of all the SVN authors (and their number of contributions) 
according to the logs:
beckerl 197
bertazza 29
bgudehus 6
clark 6
edso 1305
elnico 54
eric.lemesre 4
infinityedge 2
jammerhund 47
javamap 10
jratike80 22
kdneufeld 2
lreeder 1
ma15569 602
mentaer 465
michaudm 1619
paul_d_austin 38
s-l-teichmann 1
stranger 87

If you want to keep track of them in the possible future Git repository, a 
conversion file needs to be created, for example (with one author per line):
michaudm = Michael Michaud 

We should maybe do this outside this mailing list to avoid creating a list of 
public email addresses.

For info, I easily managed to locally create a Git repository containing the 
1.15 release of OpenJUMP, using the 6242 revision. I'm waiting for your 
different answers to move to the next step.

Best,
Eric

On 10/08/2020 14:42, Eric wrote:

Hi Ede,

Thanks for your welcome and for your answers. See my inline replies for some of 
them (I deleted the other parts).

On 09/08/2020 16:40, edgar.sol...@web.de wrote:

hey Eric,

welcome to the team! see my answers below

On 07.08.2020 20:55, Eric wrote:

Then I checked which OJ lib dependencies rely on JTS and it seems that there is 
only deegree 2,
without considering here the plethora of extensions/plugins.

which is the main obstacle. the only clean solution i see is to branch out a 
new OJ 2.x that initially will break compatibility to all external plugins. 
that's the bad news.
the good news is that this forces us to retouch pretty much all of them and 
during this effort we might eventually come up with a working plugin manager 
after all.

Less than a day of work should be required (if not less) to update all the 
plugins which do not rely on a dependency which relies itself on JTS. I'm going 
to test it, to see if it's the case.
I tried with my plugins and I just needed a couple of seconds to do it.


This is quite a good news because
if the deegree dependency is updated to its latest version (3.x.x), which 
relies on JTS 1.15,
then, theoretically, only the import statements and a few other 
com.vividsolutions directly used in the code
need to be modified.

yeah, probably not. deegree2 is afaics used primarily or exclusively for the 
WFS extension and i remember checking out deegree3 as a drop in for deegree2 
but failing miserably. that's why i stuck with deegree2 happy to have at least 
a working WFS extension for the time being.

but again, we can remove WFS from core for OJ 2.x and come up with a working 
extension later (if at all).

It seems to be a good compromise for the time being as the migration from 
deegree-core 2 to deegree-core 3 isn't straightforward.


- the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic due to 
the jts-io
pom type only, but once imported, this part of the code will be functional 
again,

how do you figure? com.vividsolutions.jump.io.geojson was written by myself 
from scratch utilizing google's json-simple . it holds no dependency apart from 
the jts geometry code. maybe myself placing it in this package has mislead you

Have a look at the GeoJsonReader class for example, and the method 
MapGeoJsonGeometryReader (see the comment), or the 
GeoJSONFeatureCollectionWrapper class. You will see that there is a dependency 
to JTS io.
It doesn't mean that there is a real dependency in the way it works, but JTS io 
(now jts-io-common which includes the GeoJSON code) is needed for the code to 
compile.


- some classes have been deprecated, removed, or simply moved in the new JTS 
versions,
such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory. New 
interfaces
have been created in JTS. It shouldn't be too complex to find a solution or a 
workaround,

agreed

After the JTS upgrade, only two classes require some changes:
- org.openjump.core.ui.plugin.tools.ReducePointsISAPlugIn -- relatively easy to 
solve,
- another written by Michaël, com.vividsolutions.jump.geom.MakeValidOp. For 
this one, a few JTS constructors have evolved. The problem is linked to the 4th 
dimension, dimension that can't be retrieved any more with a simple getter. One 
temporary solution could consist in the creation of a class which extends the 
current JTS one with an additional getter / setter for the dimension.


Once these problems of imports are solved, the JTS update should be relatively

[JPP-Devel] Git Repo ids Was:Re: OJ 2.x Was:Re: JTS update: first experiments

[edgar . soldin]

working mail addresses will be difficult to get for everyine and generally 
unnecessary as well. just need to keep the history and committer ids to enable 
retracing changes in the future as well.

..ede

On 10.08.2020 15:52, Eric wrote:
> Here is the list of all the SVN authors (and their number of contributions) 
> according to the logs:
> beckerl 197
> bertazza 29
> bgudehus 6
> clark 6
> edso 1305
> elnico 54
> eric.lemesre 4
> infinityedge 2
> jammerhund 47
> javamap 10
> jratike80 22
> kdneufeld 2
> lreeder 1
> ma15569 602
> mentaer 465
> michaudm 1619
> paul_d_austin 38
> s-l-teichmann 1
> stranger 87
>
> If you want to keep track of them in the possible future Git repository, a 
> conversion file needs to be created, for example (with one author per line):
> michaudm = Michael Michaud 
>
> We should maybe do this outside this mailing list to avoid creating a list of 
> public email addresses.
>
> For info, I easily managed to locally create a Git repository containing the 
> 1.15 release of OpenJUMP, using the 6242 revision. I'm waiting for your 
> different answers to move to the next step.
>
> Best,
> Eric
>
> On 10/08/2020 14:42, Eric wrote:
>> Hi Ede,
>>
>> Thanks for your welcome and for your answers. See my inline replies for some 
>> of them (I deleted the other parts).
>>
>> On 09/08/2020 16:40, edgar.sol...@web.de wrote:
>>> hey Eric,
>>>
>>> welcome to the team! see my answers below
>>>
>>> On 07.08.2020 20:55, Eric wrote:
 Then I checked which OJ lib dependencies rely on JTS and it seems that 
 there is only deegree 2,
 without considering here the plethora of extensions/plugins.
>>> which is the main obstacle. the only clean solution i see is to branch out 
>>> a new OJ 2.x that initially will break compatibility to all external 
>>> plugins. that's the bad news.
>>> the good news is that this forces us to retouch pretty much all of them and 
>>> during this effort we might eventually come up with a working plugin 
>>> manager after all.
>>
>> Less than a day of work should be required (if not less) to update all the 
>> plugins which do not rely on a dependency which relies itself on JTS. I'm 
>> going to test it, to see if it's the case.
>> I tried with my plugins and I just needed a couple of seconds to do it.
>>
 This is quite a good news because
 if the deegree dependency is updated to its latest version (3.x.x), which 
 relies on JTS 1.15,
 then, theoretically, only the import statements and a few other 
 com.vividsolutions directly used in the code
 need to be modified.
>>> yeah, probably not. deegree2 is afaics used primarily or exclusively for 
>>> the WFS extension and i remember checking out deegree3 as a drop in for 
>>> deegree2 but failing miserably. that's why i stuck with deegree2 happy to 
>>> have at least a working WFS extension for the time being.
>>>
>>> but again, we can remove WFS from core for OJ 2.x and come up with a 
>>> working extension later (if at all).
>>
>> It seems to be a good compromise for the time being as the migration from 
>> deegree-core 2 to deegree-core 3 isn't straightforward.
>>
 - the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic due 
 to the jts-io
 pom type only, but once imported, this part of the code will be functional 
 again,
>>> how do you figure? com.vividsolutions.jump.io.geojson was written by myself 
>>> from scratch utilizing google's json-simple . it holds no dependency apart 
>>> from the jts geometry code. maybe myself placing it in this package has 
>>> mislead you
>>
>> Have a look at the GeoJsonReader class for example, and the method 
>> MapGeoJsonGeometryReader (see the comment), or the 
>> GeoJSONFeatureCollectionWrapper class. You will see that there is a 
>> dependency to JTS io.
>> It doesn't mean that there is a real dependency in the way it works, but JTS 
>> io (now jts-io-common which includes the GeoJSON code) is needed for the 
>> code to compile.
>>
 - some classes have been deprecated, removed, or simply moved in the new 
 JTS versions,
 such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory. New 
 interfaces
 have been created in JTS. It shouldn't be too complex to find a solution 
 or a workaround,
>>> agreed
>>
>> After the JTS upgrade, only two classes require some changes:
>> - org.openjump.core.ui.plugin.tools.ReducePointsISAPlugIn -- relatively easy 
>> to solve,
>> - another written by Michaël, com.vividsolutions.jump.geom.MakeValidOp. For 
>> this one, a few JTS constructors have evolved. The problem is linked to the 
>> 4th dimension, dimension that can't be retrieved any more with a simple 
>> getter. One temporary solution could consist in the creation of a class 
>> which extends the current JTS one with an additional getter / setter for the 
>> dimension.
>>
 Once these problems of imports are solved, the JTS update should be 
 relatively
 straightforward, and some work 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[edgar . soldin]

looks unmaintained with last commit being from 2017-05-24
https://sourceforge.net/p/gvsigce/code/HEAD/tree/trunk/sextante/

..ede

On 11.08.2020 08:31, Giuseppe Aruta wrote:
> Hi Eric
>
> - This is the link to GvSIG CE SVN of Sextante:
> https://svn.code.sf.net/p/gvsigce/code/trunk/sextante
>
> - Regarding OJ binding we use. You will find the source code in  OpenJUMP 
> Plugin SVN.
> It has been modified during these years in order to a better integration wof 
> both Software (OpnJUMP and Sextante)
>  a quick list of main changes:
>
>   * better recognize of nodata values
>   * activation of modeler, and other sextante tool
>   * integration of output results interface to OpenJUMP in order to have all 
> output not vector or raster (diagrams, tables, html, etc)
>   * from OpenJUMP e from Sextante into an unique space (see classes in 
> org.openjump.sextante.gui.additionalResults from OJ SVN)
>
>
> - As far as I remember the version of Sextante we ship is "1.0". Actual GvSIG 
> version is named "1.0.0"
>
> Best regards
>
> Peppe
>
> Il giorno lun 10 ago 2020 alle ore 22:16 Eric  > ha scritto:
>
> I also found the sources for the 0.6 version here, directly exported from 
> code.google.com/p/sextante : 
> https://github.com/danieldupre/sextante
> The OpenJUMP bindings are included.
>
> Víctor Olaya could also be contacted to help if needed: 
> https://github.com/volaya
>
> Finally, I found a version 1.0 of Sextante in the 52°North project but 
> only the compiled code is accessible (in their own Maven repository). It 
> seems to be a Maven refactoring based on the 0.6 version:
> https://github.com/52North/WPS/tree/dev/52n-wps-sextante
>
> Eric
>
> On 10/08/2020 20:44, Eric wrote:
>> Thanks.
>>
>> Is it different from this repository:
>> - https://joinup.ec.europa.eu/svn/sextante/soft/sextante_lib/
>> - (OpenJUMP bindings) 
>> https://joinup.ec.europa.eu/svn/sextante/soft/bindings/openjump/
>>
>> I tried to find the source code of GvSig CE but I failed. Could you 
>> please send us a link to their SVN repository? Thanks.
>>
>> Eric
>>
>> On 10/08/2020 20:02, Giuseppe Aruta wrote:
>>> >>Less than a day of work should be required (if not less) to update 
>>> all the plugins which do not rely on a dependency which relies itself on 
>>> JTS. I'm going to test it, to see if it's the case.
>>>
>>> Possibly Sextante Will be a problem as we don't have the source code of 
>>> the project (it is available on GvSig CE svn repository). And Sextante.jar, 
>>> Sextante-gui.jar and Sextante-algorithms.jar partially rely on JTS. 
>>> I gave a look at the source code: the versione available on GvSig CE is 
>>> a bit different from the one embedded into Openjump: there are some 
>>> enhancements and few depencies to GvSig class: nothing serious as I tested 
>>> their version with Openjump and it works fine. Right now my tested version 
>>> of Openjump for raster analysis  uses GvSig CE sextante.
>>>
>>> My idea is to download Sextante source code from GvSig CE and try to 
>>> recompile it with new JTS. And prepare some tests following Sextante 
>>> documentation and user's notes (Openjump with all raster tools is used in a 
>>> couple of courses at the University of Padua) .
>>> I will also mail to GvSig CE folks. GVSIG CE (at least sextante) seems 
>>> not have activity since a couple of years.
>>> Peppe
>>>
>>>
>>>
>>>
>>>
>>> Il lun 10 ago 2020, 15:52 Eric >> > ha scritto:
>>>
>>> Here is the list of all the SVN authors (and their number of 
>>> contributions) according to the logs:
>>> beckerl 197
>>> bertazza 29
>>> bgudehus 6
>>> clark 6
>>> edso 1305
>>> elnico 54
>>> eric.lemesre 4
>>> infinityedge 2
>>> jammerhund 47
>>> javamap 10
>>> jratike80 22
>>> kdneufeld 2
>>> lreeder 1
>>> ma15569 602
>>> mentaer 465
>>> michaudm 1619
>>> paul_d_austin 38
>>> s-l-teichmann 1
>>> stranger 87
>>>
>>> If you want to keep track of them in the possible future Git 
>>> repository, a conversion file needs to be created, for example (with one 
>>> author per line):
>>> michaudm = Michael Michaud  
>>>
>>> We should maybe do this outside this mailing list to avoid creating 
>>> a list of public email addresses.
>>>
>>> For info, I easily managed to locally create a Git repository 
>>> containing the 1.15 release of OpenJUMP, using the 6242 revision. I'm 
>>> waiting for your different answers to move to the next step.
>>>
>>> Best,
>>> Eric
>>>
>>> On 10/08/2020 14:42, Eric wrote:
 Hi Ede,

 Thanks for your welcome and for your answers. See my inline 
 replies for some of them 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

Hi Eric

- This is the link to GvSIG CE SVN of Sextante:
https://svn.code.sf.net/p/gvsigce/code/trunk/sextante

- Regarding OJ binding we use. You will find the source code in  OpenJUMP
Plugin SVN.
It has been modified during these years in order to a better integration
wof both Software (OpnJUMP and Sextante)
 a quick list of main changes:

   - better recognize of nodata values
   - activation of modeler, and other sextante tool
   - integration of output results interface to OpenJUMP in order to have
   all output not vector or raster (diagrams, tables, html, etc)
   - from OpenJUMP e from Sextante into an unique space (see classes in
   org.openjump.sextante.gui.additionalResults from OJ SVN)


- As far as I remember the version of Sextante we ship is "1.0". Actual
GvSIG version is named "1.0.0"

Best regards

Peppe

Il giorno lun 10 ago 2020 alle ore 22:16 Eric 
ha scritto:

> I also found the sources for the 0.6 version here, directly exported from
> code.google.com/p/sextante: https://github.com/danieldupre/sextante
> The OpenJUMP bindings are included.
>
> Víctor Olaya could also be contacted to help if needed:
> https://github.com/volaya
>
> Finally, I found a version 1.0 of Sextante in the 52°North project but
> only the compiled code is accessible (in their own Maven repository). It
> seems to be a Maven refactoring based on the 0.6 version:
> https://github.com/52North/WPS/tree/dev/52n-wps-sextante
>
> Eric
>
> On 10/08/2020 20:44, Eric wrote:
>
> Thanks.
>
> Is it different from this repository:
> - https://joinup.ec.europa.eu/svn/sextante/soft/sextante_lib/
> - (OpenJUMP bindings)
> https://joinup.ec.europa.eu/svn/sextante/soft/bindings/openjump/
>
> I tried to find the source code of GvSig CE but I failed. Could you please
> send us a link to their SVN repository? Thanks.
>
> Eric
>
> On 10/08/2020 20:02, Giuseppe Aruta wrote:
>
> >>Less than a day of work should be required (if not less) to update all
> the plugins which do not rely on a dependency which relies itself on JTS.
> I'm going to test it, to see if it's the case.
>
> Possibly Sextante Will be a problem as we don't have the source code of
> the project (it is available on GvSig CE svn repository). And Sextante.jar,
> Sextante-gui.jar and Sextante-algorithms.jar partially rely on JTS.
> I gave a look at the source code: the versione available on GvSig CE is a
> bit different from the one embedded into Openjump: there are some
> enhancements and few depencies to GvSig class: nothing serious as I tested
> their version with Openjump and it works fine. Right now my tested version
> of Openjump for raster analysis  uses GvSig CE sextante.
>
> My idea is to download Sextante source code from GvSig CE and try to
> recompile it with new JTS. And prepare some tests following Sextante
> documentation and user's notes (Openjump with all raster tools is used in a
> couple of courses at the University of Padua) .
> I will also mail to GvSig CE folks. GVSIG CE (at least sextante) seems
> not have activity since a couple of years.
> Peppe
>
>
>
>
>
> Il lun 10 ago 2020, 15:52 Eric  ha scritto:
>
>> Here is the list of all the SVN authors (and their number of
>> contributions) according to the logs:
>> beckerl 197
>> bertazza 29
>> bgudehus 6
>> clark 6
>> edso 1305
>> elnico 54
>> eric.lemesre 4
>> infinityedge 2
>> jammerhund 47
>> javamap 10
>> jratike80 22
>> kdneufeld 2
>> lreeder 1
>> ma15569 602
>> mentaer 465
>> michaudm 1619
>> paul_d_austin 38
>> s-l-teichmann 1
>> stranger 87
>>
>> If you want to keep track of them in the possible future Git repository,
>> a conversion file needs to be created, for example (with one author per
>> line):
>> michaudm = Michael Michaud  
>>
>> We should maybe do this outside this mailing list to avoid creating a
>> list of public email addresses.
>>
>> For info, I easily managed to locally create a Git repository containing
>> the 1.15 release of OpenJUMP, using the 6242 revision. I'm waiting for your
>> different answers to move to the next step.
>>
>> Best,
>> Eric
>>
>> On 10/08/2020 14:42, Eric wrote:
>>
>> Hi Ede,
>>
>> Thanks for your welcome and for your answers. See my inline replies for
>> some of them (I deleted the other parts).
>>
>> On 09/08/2020 16:40, edgar.sol...@web.de wrote:
>>
>> hey Eric,
>>
>> welcome to the team! see my answers below
>>
>> On 07.08.2020 20:55, Eric wrote:
>>
>> Then I checked which OJ lib dependencies rely on JTS and it seems that
>> there is only deegree 2,
>> without considering here the plethora of extensions/plugins.
>>
>> which is the main obstacle. the only clean solution i see is to branch
>> out a new OJ 2.x that initially will break compatibility to all external
>> plugins. that's the bad news.
>> the good news is that this forces us to retouch pretty much all of them
>> and during this effort we might eventually come up with a working plugin
>> manager after all.
>>
>>
>> Less than a day of work should be required (if not less) to update all
>> the