On 04.04.2018 10:07, Giuseppe Aruta wrote:
> This means we have to rewrite all the code of OpenJUMP before modifing
> external plugins.
correct. and we are done with that, all the extensions, because they wont work
anymore.
sticking to 1.14 for the time being (as Mike suggested) sounds like a
Jucca, Michaël, Ede
I am working to upgrade CadPlan Jump Chart (mostly added Spanish and
Italian language files).
I did a tets to migrate that plugin to JTS 1.15.
I download the file here: https://github.com/locationtech/jts/releases and
configured build path.
I had problem with*
https://osgeo-org.atlassian.net/browse/GEOT-5954
Discussion in GeoTools list about migrating. There is an interesting note
about Jai-ext depency on Jts
2018-04-03 17:28 GMT+02:00 Michaël Michaud :
> Hi,
>
> I can't think of a good solution to migrate without pain.
>
Hi,
I can't think of a good solution to migrate without pain.
There is no hurry to migrate and we can probably make one more OJ
release with JTS 1.14. I'm curious to see how bigger projects like
Geotools, deegree, hale, udig... will manage this change.
On the other hand, JTS is one of the
s 1.15 vs 1.14 Was:Re: OpenJUMP next version
It sounds like a lot of job for OpenJUMP.
What about to write to LocationTech and show the difficulties for such changes?
Is Martin Davis still involved into the JTS project?
Peppe
2018-04-03 13:50 GMT+02:00 <edgar.sol...@web.de<mailto:edgar.s
On 03.04.2018 14:12, Giuseppe Aruta wrote:
> It sounds like a lot of job for OpenJUMP.
it will be, for us as well as for all the other jts implementing projects. it
would be really interesting, if there is a kind of - we will stick to the old,
it's stable enough - attitude out there.
> What
It sounds like a lot of job for OpenJUMP.
What about to write to LocationTech and show the difficulties for such
changes? Is Martin Davis still involved into the JTS project?
Peppe
2018-04-03 13:50 GMT+02:00 :
> hey All,
>
> had a look at it over the course of the last weeks
hey All,
had a look at it over the course of the last weeks and couldn't find a one size
fit's all solution. there are solution that allow us to map the package, but
then we still have to deal with the return types of methods, which is going to
be a lot of work.
with that information i'd