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
