Re: [JPP-Devel] OpenJUMP next version
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
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
Le 11/03/2018 à 20:25, edgar.sol...@web.de a écrit :
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.
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.
I'm pretty sure that some classes will need more care though (maybe
internal classes or final classes...)
Michaël
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
--
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
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
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
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
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
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
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
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
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
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
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
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
