Re: [JPP-Devel] jts 1.15 vs 1.14 Was:Re: OpenJUMP next version
On 04.04.2018 10:07, Giuseppe Aruta wrote: > This means we have to rewrite all the code of OpenJUMP before modifing > external plugins. correct. and we are done with that, all the extensions, because they wont work anymore. sticking to 1.14 for the time being (as Mike suggested) sounds like a very good plan to me. let's see how the other projects handle it and go from there. ..ede -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] jts 1.15 vs 1.14 Was:Re: OpenJUMP next version
Jucca, Michaël, Ede I am working to upgrade CadPlan Jump Chart (mostly added Spanish and Italian language files). I did a tets to migrate that plugin to JTS 1.15. I download the file here: https://github.com/locationtech/jts/releases and configured build path. I had problem with* feature.setGeometry* as this method referres to original com.vividsolutions.jts.geom.* path and not to org.locationtech.jts.geom.* This means we have to rewrite all the code of OpenJUMP before modifing external plugins. Peppe 2018-04-03 19:00 GMT+02:00 Giuseppe Aruta : > https://osgeo-org.atlassian.net/browse/GEOT-5954 > > Discussion in GeoTools list about migrating. There is an interesting note > about Jai-ext depency on Jts > > 2018-04-03 17:28 GMT+02:00 Michaël Michaud : > >> Hi, >> >> I can't think of a good solution to migrate without pain. >> >> There is no hurry to migrate and we can probably make one more OJ release >> with JTS 1.14. I'm curious to see how bigger projects like Geotools, >> deegree, hale, udig... will manage this change. >> On the other hand, JTS is one of the biggest strength of OpenJUMP, and >> we'll have to adopt the newer version, sooner or later. >> >> Maybe we should try to communicate a bit more (list, forum , wiki) to >> know what third parties think about this evolution. I think there are no >> much active project using OpenJUMP these days. >> >> Among project derived from OpenJUMP, I can just see Manuela (sourceforge) >> which is still in sync with OpenJUMP. Other projects like Kosmo, >> Adb-Toolbox, SkyJUMP, PirolJUMP seem to have been inactive for four years >> or more. >> >> There has been some interesting plugins since then like an OSM Map reader >> (github, 2017), a LogisticTools PlugIn (github, 2017) and a drillgis plugin >> (github, 2015). But this is not much. >> >> Michaël >> >> >> >> Le 03/04/2018 à 14:51, edgar.sol...@web.de a écrit : >> >>> On 03.04.2018 14:12, Giuseppe Aruta wrote: >>> It sounds like a lot of job for OpenJUMP. >>> it will be, for us as well as for all the other jts implementing >>> projects. it would be really interesting, if there is a kind of - we will >>> stick to the old, it's stable enough - attitude out there. >>> >>> What about to write to LocationTech and show the difficulties for such changes? Is Martin Davis still involved into the JTS project? >>> the main problem isn't the adaptation, that's mainly replacing package >>> names in imports and changing some moved classes or API incompatibilities. >>> >>> the problem for us, apart from a man power that is virtually not >>> existing for non essential tasks is: >>> >>> we have third party extensions, partly without the sources at hand. >>> >>> all these have to be adapted, compiled, zipped in a jar, just because >>> jts decided it was change the package name, without any major >>> incompatibility in the API itself. >>> >>> ..ede >>> >>> >>> >>> >>> -- >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> ___ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] jts 1.15 vs 1.14 Was:Re: OpenJUMP next version
https://osgeo-org.atlassian.net/browse/GEOT-5954 Discussion in GeoTools list about migrating. There is an interesting note about Jai-ext depency on Jts 2018-04-03 17:28 GMT+02:00 Michaël Michaud : > Hi, > > I can't think of a good solution to migrate without pain. > > There is no hurry to migrate and we can probably make one more OJ release > with JTS 1.14. I'm curious to see how bigger projects like Geotools, > deegree, hale, udig... will manage this change. > On the other hand, JTS is one of the biggest strength of OpenJUMP, and > we'll have to adopt the newer version, sooner or later. > > Maybe we should try to communicate a bit more (list, forum , wiki) to know > what third parties think about this evolution. I think there are no much > active project using OpenJUMP these days. > > Among project derived from OpenJUMP, I can just see Manuela (sourceforge) > which is still in sync with OpenJUMP. Other projects like Kosmo, > Adb-Toolbox, SkyJUMP, PirolJUMP seem to have been inactive for four years > or more. > > There has been some interesting plugins since then like an OSM Map reader > (github, 2017), a LogisticTools PlugIn (github, 2017) and a drillgis plugin > (github, 2015). But this is not much. > > Michaël > > > > Le 03/04/2018 à 14:51, edgar.sol...@web.de a écrit : > >> On 03.04.2018 14:12, Giuseppe Aruta wrote: >> >>> It sounds like a lot of job for OpenJUMP. >>> >> it will be, for us as well as for all the other jts implementing >> projects. it would be really interesting, if there is a kind of - we will >> stick to the old, it's stable enough - attitude out there. >> >> What about to write to LocationTech and show the difficulties for such >>> changes? Is Martin Davis still involved into the JTS project? >>> >> the main problem isn't the adaptation, that's mainly replacing package >> names in imports and changing some moved classes or API incompatibilities. >> >> the problem for us, apart from a man power that is virtually not existing >> for non essential tasks is: >> >> we have third party extensions, partly without the sources at hand. >> >> all these have to be adapted, compiled, zipped in a jar, just because jts >> decided it was change the package name, without any major incompatibility >> in the API itself. >> >> ..ede >> >> >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] jts 1.15 vs 1.14 Was:Re: OpenJUMP next version
Hi, I can't think of a good solution to migrate without pain. There is no hurry to migrate and we can probably make one more OJ release with JTS 1.14. I'm curious to see how bigger projects like Geotools, deegree, hale, udig... will manage this change. On the other hand, JTS is one of the biggest strength of OpenJUMP, and we'll have to adopt the newer version, sooner or later. Maybe we should try to communicate a bit more (list, forum , wiki) to know what third parties think about this evolution. I think there are no much active project using OpenJUMP these days. Among project derived from OpenJUMP, I can just see Manuela (sourceforge) which is still in sync with OpenJUMP. Other projects like Kosmo, Adb-Toolbox, SkyJUMP, PirolJUMP seem to have been inactive for four years or more. There has been some interesting plugins since then like an OSM Map reader (github, 2017), a LogisticTools PlugIn (github, 2017) and a drillgis plugin (github, 2015). But this is not much. Michaël Le 03/04/2018 à 14:51, edgar.sol...@web.de a écrit : On 03.04.2018 14:12, Giuseppe Aruta wrote: It sounds like a lot of job for OpenJUMP. it will be, for us as well as for all the other jts implementing projects. it would be really interesting, if there is a kind of - we will stick to the old, it's stable enough - attitude out there. What about to write to LocationTech and show the difficulties for such changes? Is Martin Davis still involved into the JTS project? the main problem isn't the adaptation, that's mainly replacing package names in imports and changing some moved classes or API incompatibilities. the problem for us, apart from a man power that is virtually not existing for non essential tasks is: we have third party extensions, partly without the sources at hand. all these have to be adapted, compiled, zipped in a jar, just because jts decided it was change the package name, without any major incompatibility in the API itself. ..ede -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] jts 1.15 vs 1.14 Was:Re: OpenJUMP next version
Hi, I guess that renaming the package has something to do with the license change from LGPL 2.1 to the more permissive Eclipse licenses https://projects.eclipse.org/projects/locationtech.jts for making it clear that org.locationtech.jts stuff is not derived from the LGPL licensed code but re-published from the original work by VividSolutions and Martin Davis. -Jukka Rahkonen- Lähettäjä: Giuseppe Aruta [mailto:giuseppe.ar...@gmail.com] Lähetetty: 3. huhtikuuta 2018 15:12 Vastaanottaja: OpenJump develop and use Aihe: Re: [JPP-Devel] jts 1.15 vs 1.14 Was:Re: OpenJUMP next version It sounds like a lot of job for OpenJUMP. What about to write to LocationTech and show the difficulties for such changes? Is Martin Davis still involved into the JTS project? Peppe 2018-04-03 13:50 GMT+02:00 mailto:edgar.sol...@web.de>>: hey All, had a look at it over the course of the last weeks and couldn't find a one size fit's all solution. there are solution that allow us to map the package, but then we still have to deal with the return types of methods, which is going to be a lot of work. with that information i'd suggest now is to go the scenic route - keeping jts 1.14, for legacy compatibility - add jts 1.15, it's a different package anyway - implement the new package step by step in OJ core (have core deal with both package's classes eventually eg. being able to render org.locationtech.jts.geom.* classes) - write a converter/wrapping functionality for backwards compatibility (where needed, there will be speed penalties of course) - eventually we will probably end up with OJ 2.x, just because of the plethora of incompatibilities we will fetch because of this step jts project took (really don't understand jts's reasoning, it's just so much unnecessary work!) what do you say? ..ede On 11.03.2018 20:25, edgar.sol...@web.de<mailto:edgar.sol...@web.de> wrote: > On 3/11/2018 19:54, Michaël Michaud wrote: >> >> >> Le 11/03/2018 à 18:07, edgar.sol...@web.de<mailto:edgar.sol...@web.de> a >> écrit : >>> On 3/11/2018 17:45, Michaël Michaud wrote: >>>>>>>> Migrating to jts 1.15 will probably break a lot of plugins. How do you >>>>>>>> think we should manage this migration ? >>>>>>> preferably with a compatibility layer, eg. two classloaders, one w/ >>>>>>> old, one new jts. or standin JTS classes in OJ core, that fix >>>>>>> incompatibilities on a one by one basis. >>>>>> Can you elaborate about how using two classloaders can help us ? >>>>>> I think that as soon as the new Geometry class will be used in >>>>>> Feature's, every plugin importing a Geometry from the old vividsolutions >>>>>> package will have to be changed (including extensions...) . >>>>> could you point to docs describing the changes or explain the >>>>> incompatibility between the two Geometry classes a bit more detailed? >>>> https://github.com/locationtech/jts/blob/master/MIGRATION.md >>> so it is not really an incompatibility, but they actually dared to change >>> the package name? and instead of making it generic, they made it into >>> another company name :)), well done! >> Yes, sorry if my previous mail did not make that clear. > > no problemo > >>> >>> before we start replacing all over the project let's see if we can patch >>> our classloader to simply load from the different package? that would save >>> us from digging through all extension jars and fixup imports there. >> Wow, it seems magic to me. >> Do you mean loading new jts15 classes with their old name so that they match >> current code instructions ? > > looked into it, but seems more complex then expected. something along the > lines of > > https://stackoverflow.com/questions/2897685/dynamic-loading-a-class-in-java-with-a-different-package-name > > but also not usable, as we need the old to be class compatible eg. instanceof > comparable wit the new > >> Indeed, I'm afraid about the complexity added by such a solution but if it >> could make external extension still work without change, it would be a very >> good point. >>> d'accord? ..ede >> It would be a nice temporary solution. Maybe until the next version. When >> jts will add new classes / methods, it will become very confusing. > > currently i think using shims would be the way to go. jts has less than 500 > java files. what we need to do is recreate al of them but point them to their > new package equivalent. additionally we can @deprecated them eg. > > package com.vividsolutions.jts.g
Re: [JPP-Devel] jts 1.15 vs 1.14 Was:Re: OpenJUMP next version
On 03.04.2018 14:12, Giuseppe Aruta wrote: > It sounds like a lot of job for OpenJUMP. it will be, for us as well as for all the other jts implementing projects. it would be really interesting, if there is a kind of - we will stick to the old, it's stable enough - attitude out there. > What about to write to LocationTech and show the difficulties for such > changes? Is Martin Davis still involved into the JTS project? the main problem isn't the adaptation, that's mainly replacing package names in imports and changing some moved classes or API incompatibilities. the problem for us, apart from a man power that is virtually not existing for non essential tasks is: we have third party extensions, partly without the sources at hand. all these have to be adapted, compiled, zipped in a jar, just because jts decided it was change the package name, without any major incompatibility in the API itself. ..ede -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] jts 1.15 vs 1.14 Was:Re: OpenJUMP next version
It sounds like a lot of job for OpenJUMP.
What about to write to LocationTech and show the difficulties for such
changes? Is Martin Davis still involved into the JTS project?
Peppe
2018-04-03 13:50 GMT+02:00 :
> hey All,
>
> had a look at it over the course of the last weeks and couldn't find a one
> size fit's all solution. there are solution that allow us to map the
> package, but then we still have to deal with the return types of methods,
> which is going to be a lot of work.
>
> with that information i'd suggest now is to go the scenic route
> - keeping jts 1.14, for legacy compatibility
> - add jts 1.15, it's a different package anyway
> - implement the new package step by step in OJ core (have core deal with
> both package's classes eventually eg. being able to render
> org.locationtech.jts.geom.* classes)
> - write a converter/wrapping functionality for backwards compatibility
> (where needed, there will be speed penalties of course)
> - eventually we will probably end up with OJ 2.x, just because of the
> plethora of incompatibilities we will fetch because of this step jts
> project took (really don't understand jts's reasoning, it's just so much
> unnecessary work!)
>
> what do you say? ..ede
>
> On 11.03.2018 20:25, edgar.sol...@web.de wrote:
> > On 3/11/2018 19:54, Michaël Michaud wrote:
> >>
> >>
> >> Le 11/03/2018 à 18:07, edgar.sol...@web.de a écrit :
> >>> On 3/11/2018 17:45, Michaël Michaud wrote:
> Migrating to jts 1.15 will probably break a lot of plugins. How
> do you think we should manage this migration ?
> >>> preferably with a compatibility layer, eg. two classloaders, one
> w/ old, one new jts. or standin JTS classes in OJ core, that fix
> incompatibilities on a one by one basis.
> >> Can you elaborate about how using two classloaders can help us ?
> >> I think that as soon as the new Geometry class will be used in
> Feature's, every plugin importing a Geometry from the old vividsolutions
> package will have to be changed (including extensions...) .
> > could you point to docs describing the changes or explain the
> incompatibility between the two Geometry classes a bit more detailed?
> https://github.com/locationtech/jts/blob/master/MIGRATION.md
> >>> so it is not really an incompatibility, but they actually dared to
> change the package name? and instead of making it generic, they made it
> into another company name :)), well done!
> >> Yes, sorry if my previous mail did not make that clear.
> >
> > no problemo
> >
> >>>
> >>> before we start replacing all over the project let's see if we can
> patch our classloader to simply load from the different package? that would
> save us from digging through all extension jars and fixup imports there.
> >> Wow, it seems magic to me.
> >> Do you mean loading new jts15 classes with their old name so that they
> match current code instructions ?
> >
> > looked into it, but seems more complex then expected. something along
> the lines of
> > https://stackoverflow.com/questions/2897685/dynamic-
> loading-a-class-in-java-with-a-different-package-name
> >
> > but also not usable, as we need the old to be class compatible eg.
> instanceof comparable wit the new
> >
> >> Indeed, I'm afraid about the complexity added by such a solution but if
> it could make external extension still work without change, it would be a
> very good point.
> >>> d'accord? ..ede
> >> It would be a nice temporary solution. Maybe until the next version.
> When jts will add new classes / methods, it will become very confusing.
> >
> > currently i think using shims would be the way to go. jts has less than
> 500 java files. what we need to do is recreate al of them but point them to
> their new package equivalent. additionally we can @deprecated them eg.
> >
> > package com.vividsolutions.jts.geom;
> >
> > /**
> > * @deprecated use the other one
> > */
> > @Deprecated
> > public class Coordinate extends org.locationtech.jts.geom.Coordinate {
> > }
> >
> > having these in core under com.vividsolutions.jts or in a specific jar
> should resolve legacy issues instantly.
> >
> > now thinking up a routine that takes over most if the src code creation.
> something hackish iterating over the jts sources and creating the above
> mentioned sources that then will need some finetuning only hopefully.
> >
> >> I just checked some famous libraries using jts.
> >> Seems like deegree still use jts1.13 and geotools still use jts1.14.
> >
> > they probably know why :)
> >
> > ..ede
> >
> > PS: good fit - http://dilbert.com/strip/2018-03-11
> >
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
>
>
[JPP-Devel] jts 1.15 vs 1.14 Was:Re: OpenJUMP next version
hey All,
had a look at it over the course of the last weeks and couldn't find a one size
fit's all solution. there are solution that allow us to map the package, but
then we still have to deal with the return types of methods, which is going to
be a lot of work.
with that information i'd suggest now is to go the scenic route
- keeping jts 1.14, for legacy compatibility
- add jts 1.15, it's a different package anyway
- implement the new package step by step in OJ core (have core deal with both
package's classes eventually eg. being able to render
org.locationtech.jts.geom.* classes)
- write a converter/wrapping functionality for backwards compatibility (where
needed, there will be speed penalties of course)
- eventually we will probably end up with OJ 2.x, just because of the plethora
of incompatibilities we will fetch because of this step jts project took
(really don't understand jts's reasoning, it's just so much unnecessary work!)
what do you say? ..ede
On 11.03.2018 20:25, edgar.sol...@web.de wrote:
> On 3/11/2018 19:54, Michaël Michaud wrote:
>>
>>
>> Le 11/03/2018 à 18:07, edgar.sol...@web.de a écrit :
>>> On 3/11/2018 17:45, Michaël Michaud wrote:
Migrating to jts 1.15 will probably break a lot of plugins. How do you
think we should manage this migration ?
>>> preferably with a compatibility layer, eg. two classloaders, one w/
>>> old, one new jts. or standin JTS classes in OJ core, that fix
>>> incompatibilities on a one by one basis.
>> Can you elaborate about how using two classloaders can help us ?
>> I think that as soon as the new Geometry class will be used in
>> Feature's, every plugin importing a Geometry from the old vividsolutions
>> package will have to be changed (including extensions...) .
> could you point to docs describing the changes or explain the
> incompatibility between the two Geometry classes a bit more detailed?
https://github.com/locationtech/jts/blob/master/MIGRATION.md
>>> so it is not really an incompatibility, but they actually dared to change
>>> the package name? and instead of making it generic, they made it into
>>> another company name :)), well done!
>> Yes, sorry if my previous mail did not make that clear.
>
> no problemo
>
>>>
>>> before we start replacing all over the project let's see if we can patch
>>> our classloader to simply load from the different package? that would save
>>> us from digging through all extension jars and fixup imports there.
>> Wow, it seems magic to me.
>> Do you mean loading new jts15 classes with their old name so that they match
>> current code instructions ?
>
> looked into it, but seems more complex then expected. something along the
> lines of
>
> https://stackoverflow.com/questions/2897685/dynamic-loading-a-class-in-java-with-a-different-package-name
>
> but also not usable, as we need the old to be class compatible eg. instanceof
> comparable wit the new
>
>> Indeed, I'm afraid about the complexity added by such a solution but if it
>> could make external extension still work without change, it would be a very
>> good point.
>>> d'accord? ..ede
>> It would be a nice temporary solution. Maybe until the next version. When
>> jts will add new classes / methods, it will become very confusing.
>
> currently i think using shims would be the way to go. jts has less than 500
> java files. what we need to do is recreate al of them but point them to their
> new package equivalent. additionally we can @deprecated them eg.
>
> package com.vividsolutions.jts.geom;
>
> /**
> * @deprecated use the other one
> */
> @Deprecated
> public class Coordinate extends org.locationtech.jts.geom.Coordinate {
> }
>
> having these in core under com.vividsolutions.jts or in a specific jar should
> resolve legacy issues instantly.
>
> now thinking up a routine that takes over most if the src code creation.
> something hackish iterating over the jts sources and creating the above
> mentioned sources that then will need some finetuning only hopefully.
>
>> I just checked some famous libraries using jts.
>> Seems like deegree still use jts1.13 and geotools still use jts1.14.
>
> they probably know why :)
>
> ..ede
>
> PS: good fit - http://dilbert.com/strip/2018-03-11
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Jump-pilot-devel mailing list
Jump-pilot-
