Le 11/03/2018 à 20:25, edgar.sol...@web.de a écrit :
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.
This solution looks better to me as it is more oriented toward the new
package (new code can be written with the new package name).
If it works fine, we could migrate OpenJUMP slowly toward the new
package name and keep this solution only to solve compatibility
problems arising on not-yet-migrated plugins/extensions.
I'm pretty sure that some classes will need more care though (maybe
internal classes or final classes...)
Michaël
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
