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
