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 

actually i'd say switching in the middle of the year would suffice unless you 
are planning to use java8+ features already?


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

Reply via email to