Re: [JPP-Devel] OpenJUMP next version

[Giuseppe Aruta]

Checking on GvSIG CE svn, Sextante
* the main library (sextante.jar) depends on  jts 1.12
* The other Sextante libraries (sextante-gui.jar, libMath.jar and
Sextante-algorithms.jar) don't seem to have depency to jts





2018-03-12 0:15 GMT+01:00 :

> On 3/11/2018 23:40, Michaël Michaud wrote:
> >> 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.
>
> that's the idea :)
>
> >
> > I'm pretty sure that some classes will need more care though (maybe
> internal classes or final classes...)
>
> jupp, but we'll see about them. most extensions probably do not use JTS in
> such fine detail.. 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

Re: [JPP-Devel] OpenJUMP next version

[edgar . soldin]

On 3/11/2018 23:40, Michaël Michaud wrote:
>> 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.

that's the idea :)

> 
> I'm pretty sure that some classes will need more care though (maybe internal 
> classes or final classes...)

jupp, but we'll see about them. most extensions probably do not use JTS in such 
fine detail.. 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

Re: [JPP-Devel] OpenJUMP next version

[edgar . soldin]

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.

> 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

Re: [JPP-Devel] OpenJUMP next version

[Michaël Michaud]

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.


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 ?
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.


I just checked some famous libraries using jts.
Seems like deegree still use jts1.13 and geotools still use jts1.14.

Michaël




--
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

Re: [JPP-Devel] OpenJUMP next version

[edgar . soldin]

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!

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.

d'accord? ..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

Re: [JPP-Devel] OpenJUMP next version

[Michaël Michaud]

Hi Brian,

Thanks for the reminder. Let us know when the ubuntu/java version will 
be decided.


Anyway, the recent OpenJUMP 1.12 is compatible with java 7, so that an 
upgrade of

OpenJUMP in the next OSGeoLive should be possible anyway.

Michaël


Le 11/03/2018 à 17:21, Brian M Hamlin a écrit :
On Sun, 11 Mar 2018 08:21:42 0100, Michaël Michaud 
 wrote:

   One of the next big step will be to migrate to jts 1.15 and java 1.8.
   Migrating to jts 1.15 will probably break a lot of plugins. How do you
      think we should manage this migration ?
-
Hello All -

  A gentle reminder, that the OSGeoLive project [0][1] has begun the very
earliest "call for development" for the upcoming build cycle.
  Internally, it is not yet decided which Ubuntu OS version will be 
the base,

which in turn directly determines the Java version available.

  Please feedback early and often so we can together make a great 
OSGeoLive.   sincere thanks and best regards from Berkeley, California




[0]  https://live.osgeo.org
[1]  https://git.osgeo.org/gitea/osgeolive/OSGeoLive

--
Brian M Hamlin
OSGeo California
blog.light42.com







--
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

Re: [JPP-Devel] OpenJUMP next version

[Stefan Steiniger]

With respect to the branching issue...

It may be a silly idea, but how about migrating to and importing to 
github - as a solution?


The last stable version will then be on SVN and work with the new JTS 
will be on Github. So the SVN version is always intact/a back-up for 
later on.


But of course, I have no idea what you actually think about Github...

cheers,
stefan

PS: ede, i managed to download the new OJ version, but I did not even 
manage to install/open the zip due to a lack of time (I have to hand in 
my 3-year advancements research project report by next week ). So no 
promises at all.


On 3/11/18 13:20, edgar.sol...@web.de wrote:

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



--
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

Re: [JPP-Devel] OpenJUMP next version

[Michaël Michaud]

Ede,

Le 11/03/2018 à 17:20, edgar.sol...@web.de a écrit :

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+ .

OK,



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?

https://github.com/locationtech/jts/blob/master/MIGRATION.md



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?
I would be pleased to make use of java8 features, but there is nothing 
urgent.


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

Re: [JPP-Devel] OpenJUMP next version

[Brian M Hamlin]

On Sun, 11 Mar 2018 08:21:42 0100, Michaël Michaud 
 wrote:
   One of the next big step will be to migrate to jts 1.15 and java 1.8. 


   Migrating to jts 1.15 will probably break a lot of plugins. How do you
      think we should manage this migration ?
-
Hello All -
 
  A gentle reminder, that the OSGeoLive project [0][1] has begun the very
earliest "call for development" for the upcoming build cycle. 
 

  Internally, it is not yet decided which Ubuntu OS version will be the base,
which in turn directly determines the Java version available.  
 
  Please feedback early and often so we can together make a great OSGeoLive. 
  sincere thanks and best regards from Berkeley, California

 
 
 
[0]  https://live.osgeo.org
[1]  https://git.osgeo.org/gitea/osgeolive/OSGeoLive

--
Brian M Hamlin
OSGeo California
blog.light42.com

 


--
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

Re: [JPP-Devel] OpenJUMP next version

[edgar . soldin]

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

Re: [JPP-Devel] OpenJUMP next version

[Michaël Michaud]

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

Re: [JPP-Devel] OpenJUMP next version

[Giuseppe Aruta]

Hi Michaël,
I don't have the experience about it
Nevertheless I feel that the first your  proposal is more easy to manage,
as we are a small comunity of developers.
Peppe


2018-03-11 8:21 GMT+01:00 Michaël Michaud :

> Hi Jumpers,
>
> One of the next big step will be to migrate to jts 1.15 and java 1.8.
>
> Migrating to jts 1.15 will probably break a lot of plugins. How do you
> think we should manage this migration ?
>
> 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.
>
> Or should we make another branch for important fixes on 1.12 ?
>
> Michaël
>
>
> 
> --
> 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

Re: [JPP-Devel] OpenJUMP next version

[edgar . soldin]

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

>and java 1.8.

same here, currently i see no incompatibilities. what changes do you propose 
exactly?

> 
> 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.

> 
> 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.

> 
> 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?)
- are there drawbacks to declare OJ Core java8+ compatible instantly (i see 
none)

..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