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
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...) .
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.
Michaël
..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
------------------------------------------------------------------------------
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
