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>:
> 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-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
