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

Reply via email to