Hi,
>>> On 07.08.2020 20:55, Eric wrote:
>>>> Then I checked which OJ lib dependencies rely
on JTS and it
seems that
there is only deegree 2,
>>>> without considering here the plethora of
extensions/plugins.
>>> which is the main obstacle. the only clean
solution i see is
to
branch out
a new OJ 2.x that initially will break compatibility to
all external
plugins.
that's the bad news.
>>> the good news is that this forces us to retouch
pretty much
all
of them and
during this effort we might eventually come up with a
working plugin
manager
after all.
>> Less than a day of work should be required (if
not less) to
update all the
plugins which do not rely on a dependency which relies
itself on JTS.
I'm going
to test it, to see if it's the case.
>> I tried with my plugins and I just needed a
couple of seconds
to
do it.
again. we don't have sources for all extensions in OJ Plus
at hand or
setup to
build at all. the challenge won't be the modding but the
finding and
setting up
plugin repos.
I wasn't aware of this situation. All of a sudden, it
seems to be
another challenge to migrate all the plugins...
Could we decide to norrow openjump-plus to extensions
hosted by the
project
only, and revide the idea of a plugin manager (could be a
student
project ?).
there is a critical bug opening JMP project files which
should be
fixed
before
we branch
https://sourceforge.net/p/jump-pilot/bugs/496/
The idea here is to test the migration based on the OJ
1.15 release,
to
know if it works and to see what could be improved during
the final
migration. Nothing definitive.
We'll try to fix this bug before the definitive migration.
Any format preference for this document? MD (Markdown) or RST
(reStructuredText)? Both are easily and directly readable
from GitHub
/
GitLab. I would probably suggest Markdown as it's slightly
more
common
and because we don't need the specificities of RST at this
stage.
I also suggest markdown for the same reasons
>> - (Bonus) Upgrading the Log4j dependency to v2
and therefore
removing the
current security issue in link with it.
the reason that this was not done before is that some
extensions were
compiled
against it. as we are doing a clean break anyway i am not
opposed
anymore. note:
we have our "own" com.vividsolutions.jump.workbench.Logger
which is
supposed to
be the one stop solution for extension but internally uses
Log4J
again.
What I could do is, once JTS and the OJ code have been
updated on the
master branch, to create another branch (based on the
latter) to test
a
Log4j update. What do you think?
It is good for me,
>> Open discussion:
>> - Preliminary remark: I don't want at any point
of this
process,
acting as
if I was taking this project under my umbrella/name. As I
wrote to
Michaël,
you're the drivers/guardians of this project, I'm just a
passenger.
Therefore,
just let me know what you prefer, the way you want to do
things, and
I'll act
accordingly. Thanks,
thanks for contributing your time and effort!
It's the least I can do after having used OJ for years.
I this migration to github and jts 1.17 succeeds, it will
be a major
step in the
evolution of the project, thanks for your effort,
>> - Would you prefer an open or a private
repository? Why do I
consider the
private option here? To avoid any confusion with the
current OpenJUMP
repository
on sourceforge and to avoid some possible premature forks,
we can easily add notes in the Readme pointing out the
provisional
status of the
OJ2 development. anyone wanting to fork still i have no
objections.
after all
it's not called open source for nothing ;)
I'm waiting some other answers (from Peppe, Michaël, etc.)
on that.
If
none, I'll create a public repository.
I would say let's be open from the start, but I like the
following
proposition
to have an openjump/openjump-test project first (or maybe
openjump/openjump-migration), the time to fix main
problems before we
create a
more official openjump/openjump (to avoid to send a bad
image of a
project with
plenty of inconsistencies).
>> - Where do I need to create this project? In my
personal
account,
or an
OpenJUMP organisation is created, and the project takes
place there
(I
would
personally prefer this option, in link with my preliminary
remark)?
If
an
OpenJUMP organisation is created, do you want to create it
yourself
or
is it OK
if I create it?
is "organisation" something like a team definition
provided by
github/-lab ?
Yes indeed. The term "organisation" is used by GitHub, and
the terms
"group" and "subgroup" are used by GitLab:
- (GitHub)
https://github.blog/2010-06-29-introducing-organizations/
- (GitLab) https://docs.gitlab.com/ee/user/group/
An Organisation and a Group can contain several projects.
It is quite
useful to easily link related projects. In the OJ context,
one
project
could be the OJ core, another one the default plugins,
another the
PLUS
plugins, etc. (or a different project for each plugin).
Even if there is no real convention (afaik), organisations
and groups
are often written in lower case with hyphens if necessary.
For
example:
- https://github.com/geotools/geotools
- https://github.com/locationtech/jts
So for OpenJUMP I would suggest:
- openjump for the organisation / group,
- openjump for the main code,
- openjump-test for the temporary project we are talking
about here,
to
avoid any confusion.
Let me know if you agree with this naming, and what to do,
i.e. do
you
want that I create this organisation / group or if you
prefer doing
it?
If you let me do it, I'll transfer immediately the
ownership to all
of
you.
It is OK for me (consider openjump-migration as an
alternative to
openjump-test). Maybe we could also consider the name
openjump2 to
underline the
potential compatibility problems users may encounter if
they use
external
plugins. We'll also have to decide about some conventions for
projects
of the
same organisation hosting extensions : I would suggest to
always
include the
word plugin (or extension) in th eproject name, except for
special
cases like
sextante if we clone the code in openjump/.
>> - Have you already got some GitHub/GitLab
accounts that I could
use to let
you access the project as administrators?
sure, https://github.com/edeso
and https://github.com/mukoki
Thanks.
>> So if I sum up the questions:
>> - Github vs Gitlab,
>> - Open vs private repository (just for the period
of this
test),
>> - Where? Personal account vs OpenJUMP organisation,
>> - GitHub/GitLab accounts for administration.
for preliminary testing on your side feel free to use
whichever
service
private/public shouldn't matter. for an eventual fork
actually used
as
basis for
OJ2 development let's still talk about details. i'm (and
probably the
others as
well) not very familiar with setting up projects on either
github/-lab.
If you're happy with a public one, it's probably better as
we'll
benefit
from better CI/CD tools. This should allow us to test the
current OJ
builds, maybe to try different ones if necessary or at
least to adapt
the current process within the context of GitHub/GitLab,
as it
appeared
to be a crucial aspect of the migration.
This is really a test to see the feasibility (Git
migration, JTS
update,
OJ code update consequently, builds, plugins update, etc.)
-- based
on
the current OJ 1.15 release for now --, to document the
different
undertaken steps in order to be able to reproduce them if
needed and
when decided (for example to create OJ 2.x).
>> About Ede's b2 point: I tested OJ with a Java 11
environment
both
with
OpenJDK and an Oracle one. It works with both, as far as I
tested it.
I
didn't
try with Java 14. I prefer using OpenJDK as there is no
commercial
restriction
with it.
>>
agreed, we should strive to be openjdk compatible exactly
because of
the
restrictions that Oracle introduced on their java runtime.
>> Please let me know what you prefer and I'll act
accordingly.
up to you, risking that licensing might not be possible,
you may work
out a
proper conversion routine to a git service of your choice.
using your
documentation we may then using OJ 1.15.1/1.16 as a base
for OJ2
development
when/if the licensing is cleared up.
maybe you can shed a light which you think would be the
better choice
(github/-lab)?
As a lot of other GIS related projects are already on
GitHub, such as
JTS, GeoTools, GeoNode, etc., it seems that it would be a
good place
to
start with. Some projects like GEOS are directly hosted by
OSGeo,
then
mirrored on GitHub and GitLab, and thus benefiting from
different
CI/CD
tools.
Quick summary about the current options:
- choice of GitHub,
- creation of an openjump (lowercase) organisation in
GitHub --
question: who does this creation? if you let me do it, I
transfer the
co-ownership to Ede, Michaël and Peppe (others?) as soon
as I know
their
individual GitHub accounts (already known for Ede). This
organisation
has a link to the OpenJUMP website, to the OJ mailing list
(jump-pilot-devel@lists.sourceforge.net)
- creation of a openjump-test (lowercase) repository
within this
organisation,
- this repository is a public one,
- migration of the OJ core (1.15 release -- revision 6242)
containing
the trunk, tags and branches to the openjump-test
repository -- being
aware that there is a critical bug reported here:
https://sourceforge.net/p/jump-pilot/bugs/496/,
- this migration uses
<sfnetusername>@users.sourceforge.net for the
authors (i.e. all committers), and keeps the history since
the first
available SVN revision (using the logs, it seems to be the
859),
- update of JTS (version 1.17) including the update of
related OJ
code
(solving the two classes mentioned in my previous
message), the
update
of pom.xml, the removal of deegree-core 2 / deejump code
(basically
WFS
related code), the creation of a README.md or .rst to
clearly state
that
this a migration/update test and a link to the current
releases /
code,
the creation of a documentation / report about this
migration at the
root of the repository named MIGRATION.md,
- later, creation of another branch to test if it's
possible to use
Log4j v2.
Ede, Michaël and Peppe, could you let me know if you agree
or/and
disagree about one or several aspects of this list.
Once all your answers are received and a compromised
reached, I'll
proceed accordingly.
Best,
Eric
so far.. thanks! ede
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
