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 <jump-pilot-devel@lists.sourceforge.net>
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 <edgar.sol...@web.de<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.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<mailto: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<mailto: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
