On 3/11/2018 17:14, Michaël Michaud wrote:
> 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
> 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
> No, switching to java8+ is not a problem. We can switch it in maven from now
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