On 3/11/2018 17:14, Michaël Michaud wrote: > Hi, > > Le 11/03/2018 à 13:36, edgar.sol...@web.de a écrit : >> hey Mike, >> >> On 3/11/2018 8:21, Michaël Michaud wrote: >>> Hi Jumpers, >>> >>> One of the next big step will be to migrate to jts 1.15 >> let's do those as usual in trunk > OK, we just need to anticipate consequences as we'll probably not have the > capacity to upgrade all extensions. >> >>> and java 1.8. >> same here, currently i see no incompatibilities. what changes do you propose >> exactly? > Just wanted to make sure that everybody is ok to switch to java 1.8. There is > no migration problem
then let's just see if major issues pop up w/ OJ 1.12 in let's say 30 days, we can declare trunk java8+ . > and the question is not related to the jts1.5 switch. > >> >>> 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? > >> >>> I think we can start this migration on the trunk, and if something need o >>> be fixed on OpenJUMP 1.12, fix it on 1.12 tag. >> yeah, no ;). tags are immutable. > Ah, ok. >> >>> Or should we make another branch for important fixes on 1.12 ? >> we would actually need a branch for this, which i don't like because of the >> management overhead. >> >> let's talk about it some more, before we settle on a decision. >> >> main points for me are >> - what possibly breaks w/ new JTS (Mike?) > As stated before, new jts version use a new package name. So I think > everything will be broken as soon as we'll use the new Geometry. > I think we can migrate most plugins of OpenJUMP CORE, but migrating all > extensions is a lot of work and there is a major risk that we never finish. > As I cannot see a simple mechanism to keep everything working while migrating > to the new JTS, I think that having a stable branch that we can patch until > we have a new working OJ version would be reassuring. Also I admit that we > don't really have the capacity to maintain two branches. >> - are there drawbacks to declare OJ Core java8+ compatible instantly (i see >> none) > No, switching to java8+ is not a problem. We can switch it in maven from now > on. as said, let's wait if we have to do a OJ 1.12 (officially java7+ still) patch soonish. actually i'd say switching in the middle of the year would suffice unless you are planning to use java8+ features already? ..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
