Future of openwig

[bekuno]

Currently defined in the project:

    // openwig with extentions
    implementation 'com.github.biylda:openwig:3a1e405'

What do we want to do in future?

[Lineflyer]

What do you mean?

I know, that while discussing the way forward to take over the project, menion contacted the author of openwig and he was fine, that we can use it.
Or is this about something else?

[bekuno]

"use" means to take over the repo?
Do we know if it is used somewhere else?

[Lineflyer]

Oh, now I see, its a different repo.

[bekuno]

Yes, originally https://github.com/matejcik/openwig

[Lineflyer]

The author, which I refered to above is @matejcik
The mastr repository is at https://github.com/matejcik/openwig

@matejcik Any suggestion of how to proceed the integration of openwig into WhereYouGo in a best possible way? Shall we refer to your repo or make our own fork?

[matejcik]

Hello!
At this point I haven't touched the code in years, and while I do intend to come back to the project at some point, you shouldn't need to wait for that :) @biylda's fork has some modifications that I didn't manage to backport.

I'll be happy to add some of you as maintainers to my repository, if you like. Or feel free to create your own fork, at which point I'll probably archive mine and set a link to yours.

Just a friendly reminder that my code is licenced under GPLv2+, which means that the fork will need to keep that licence. I've made exceptions in the past, and I'm willing to relicence under something not strictly GPL for the fork, but the conditions I care about is (a) openwig itself will be open-source and (b) any code using openwig will be open-source.

[Lineflyer]

Hi @matejcik ,
thanks for coming back to us on that matter.
I think best will be to take a fork into our organizations repository as this has the highest probability to keep maintained over the years as our team (and amount of admins of the repo) is rather big.

We should probably take then take the fork from https://github.com/biylda/openwig as it has some modifications (as you mentioned) and was proven working with WhereYouGo in the past.

For sure we will take over under GPL or some other appropriate license. As you might know, c:geo is also open-source. I have to admit, that I do not know the detailed differences between GPL and its versions and Apache V2 (which is used by c:geo). @cgeo/team Any preference here?

[bekuno]

For a short license compare GPL vs apache see https://www.gnu.org/licenses/license-list.html.en#apache2
But we should compare to WhereYouGo, which has a GPLv3 license, see https://code.google.com/archive/p/android-whereyougo.

[bekuno]

In WhereYouGo are used 14 classes from openwig. They are all from the OpenWIGLibrary https://github.com/matejcik/openwig/tree/master/OpenWIGLibrary/src/cz/matejcik/openwig.

So I have an idea, but don't know if this can be realized.
To not collidate with other code in the openwig proroject we could integrate the OpenWIGLibrary as a subproject in WhereYouGo.

[Lineflyer]

To not collidate with other code in the openwig proroject we could integrate the OpenWIGLibrary as a subproject in WhereYouGo.

I don't know exactly what you mean with that. I think we basically have three options:

• Clone the project into an own repository on our organization
• Clone the project into a subfolder of the WhereYouGo repository on our organization (if that makes any sense programming wise)
• Keep the dependency and pull from the remote repository

[Narrat]

Git has a feature called submodule, which references another repository at state x. So no need to include the whole source of another project.
See https://git-scm.com/book/en/v2/Git-Tools-Submodules

[bekuno]

To not collidate with other code in the openwig proroject we could integrate the OpenWIGLibrary as a subproject in WhereYouGo.

I don't know exactly what you mean with that. I think we basically have three options:

* Clone the project into an own repository on our organization

* Clone the project into a subfolder of the WhereYouGo repository on our organization (if that makes any sense programming wise)

* Keep the dependency and pull from the remote repository

The second point.
Maybe it can be realized similar to the implementation project(":mapswithme-api") in c:geo.
The problem that I see is that openwig is not only a Java library, but also a GUI application and many parts are written in LUA. It could be that one day after necessary changes it will not compile anymore.

[Lineflyer]

Git has a feature called submodule, which references another repository at state x. So no need to include the whole source of another project.
See https://git-scm.com/book/en/v2/Git-Tools-Submodules

@bekuno That feature looks like what you are asking for.
After reading through it, my question is, whether we add the remote repository (from @matejcik or @biylda ) as a submodule in to cgeo/WhereYouGo or whether we clone one of those repos int our organization and then use the submodule linking.

But why exactly would you like to use a submodule rather than a simple clone of the OpenWIG into cgeo/OpenWIG?

[matejcik]

If I may?
Don't use submodules for this :) They are unsuitable for your usecase, and will be more trouble than they're worth.

Realistically there are two ways that make sense IMHO:

1. Fork the repository from me or @biylda into cgeo/OpenWIGLibrary (keeping only that subdirectory, discarding the others), make sure it cleanly builds into a jar, and import it like implementation: com.github.cgeo:openwig@v1.0.0
   My slight preference would be for this, because that way OpenWIGLibrary stays a stand-alone component that can be imported into other projects.
   The drawback is that any development or maintenance you do on openwig, you do in a separate repository, then you'll need to bump the referenced version in WhereYouGo, see if the changes work, lather, rinse, repeat.
2. Copy contents of OpenWIGLibrary directly into the WhereYouGo repository and integrate tightly. There are ways to accomplish this without losing commit history, but maybe it's not even worth that. Disadvantage is that your version becomes impossible to reuse outside of WhereYouGo. Advantage is that further development is hassle-free.

A middle ground between the two is using https://github.com/ingydotnet/git-subrepo - the relevant directory will be part of the WhereYouGo tree, but you can easily export it as a separate OpenWIGLibrary repository for reuse by others.

[bekuno]

@matejcik
Thanks for your great answer.

I have read the documentation for git sub-module and also think that this is too complicated and can lead to more problems than necessary for this small use case.

You describe the problem clear for option 1: The drawback is that any development or maintenance you do on openwig, you do in a separate repository, then you'll need to bump the referenced version in WhereYouGo, see if the changes work, lather, rinse, repeat. On the other hand if we only clone the OpenWIGLibrary part then we do not have to consider the other parts of openwig and this should not lead to complications.

Option 2 would be simpler for further development. If no major changes to openwig are necessary then option 1 should be sufficient. For major changes, the integration can be done as git-subrepo or directly later.

In either option, I would suggest we switch the build process to Gradle.

[Lineflyer]

AFAIK with option 2 we will lose the commit history and any possible binding to the original repo, correct?
So my preference would be option 1 as this is also I dare to try myself with my Git knowledge.

Decision?

[Lineflyer]

Additional question as I cannot judge it from code perspective:
What would be the repository, which we should clone?
AFAICS the biylda/openwig is what is currently used (com.github.biylda:openwig:3a1e405). So we should clone this one rather than the orignial from @matejcik ?

[bekuno]

I think we should use biylda/openwig. Then the master branch should be updated from matejcik/master (only one commit).
The biylda:openwig:3a1e405 commit is the latest from his whereyougo branch. If this can be pushed to master then let us use this result, otherwise we should use the whereyougo branch as base for the new master branch.

@matejcik Is there other work on your branches you would see in the code base? Or better not merge the work of biylda on master?

[Lineflyer]

Just a friendly reminder that my code is licenced under GPLv2+, which means that the fork will need to keep that licence. I've made exceptions in the past, and I'm willing to relicence under something not strictly GPL for the fork, but the conditions I care about is (a) openwig itself will be open-source and (b) any code using openwig will be open-source.

@matejcik
Would you be fine with GPL v3. In this case we have just the same license as WhereYouGo itself, which might make sense a bit easier?

[Lineflyer]

I started cloning and copying for what I think might be useful into https://github.com/cgeo/openWIG
These are the branches created (commit history should be unchanged):

• master --> Clone of biylda/openwig master
• whereyougo --> Clone of biylda/openwig whereyougo
• matejcik_master --> Clone of matejcik/openwig master
• matejcik_wherigeooh --> Clone of matejcik/openwig wherigeooh

I will add the LICENSE file once @matejcik replied regarding GPLv2 vs. GPLv3.

@bekuno @matejcik
Please kindly try to check if we have all we need. I guess it might be too much, but this way we can merge, delete as we like. Especially for the branches whereyougo and matejcik_whereigeooh it seems like some development took place in parallel and independently of each other.

[bekuno]

biylda/openwig/release ? or wheryougo ?

[Lineflyer]

Ups sorry, corrected:

• master --> Clone of biylda/openwig master
• whereyougo --> Clone of biylda/openwig whereyougo
• matejcik_master --> Clone of matejcik/openwig master
• matejcik_wherigeooh --> Clone of matejcik/openwig wherigeooh

Edit:
We can however rename whereyougo to release later onto have a common understanding/naming.

[bekuno]

How about make

• rename master to biylda_master
• rename whereyougo to biylda_whereyougo
• clone biylda_whereyougo to master and release

Then we have a fresh start.

[Lineflyer]

Names for branches and status are not so important in a git system, anyhow it kind of makes sense for understanding. I would just ommit biylda_whereyougo as it would be a exact clone of two others. Will take a look.

How about @matejcik proposal to throw away anything but the folder OpenWIGLibrary for our purpose? I could apply this on the final master and release branches if this is OK. I just don't have any insights about openwig, so I rely on your instruction.

[bekuno]

The idea of a branch biylda_whereyougo and biylda_master is to preserve the development state in the moment of takeover.

After this we can easier remove all parts except 'OpenWIGLibrary'.

[bekuno]

Now create a release. (1.0.0 ?)

With help of JitPack (https://github.com/jitpack/jitpack.io) we are able to include it initial as
implementation 'com.github.cgeo:openwig:1.0.0'

[Lineflyer]

Branch changes done as requested. Good night :)

[matejcik]

@matejcik Is there other work on your branches you would see in the code base? Or better not merge the work of biylda on master?

my repository state is something like "in the middle of designing a new API". I wouldn't touch it if I were you :) biylda's fork is known working with WhereYouGo AFAIK, so I'd simply go with that and not complicate matters. If you want to get up and running quickly anyway.

@matejcik
Would you be fine with GPL v3. In this case we have just the same license as WhereYouGo itself, which might make sense a bit easier?

Yes, absolutely. My licence is "GPL v2 or higher", so GPL v3 is applicable directly.

How about @matejcik proposal to throw away anything but the folder OpenWIGLibrary for our purpose? I could apply this on the final master and release branches if this is OK. I just don't have any insights about openwig, so I rely on your instruction.

There are three major projects in the repository:

• mobile is the original J2ME OpenWIG application
• DesktopWIG is a J2SE desktop GUI app
• OpenWIGLibrary is the common part, which is the only thing used in WhereYouGo
• droidwig is something like "i tried to write an Android app years ago", before menion actually did one;
• OpenWIGTester is something like a runner for logs, or for savefiles, something or other, mostly a debugging tool. You don't need it.
• kahlua things are linked from the kahlua2 repository, and are there only for ease of building. You will need to set up build so that the kahlua2 jar(s?) is (are) accessible, but perhaps Gradle can do that for you. In any case you do not need any actual content of these directories.

I see no reason for you to continue development on the J2ME app or the desktop GUI app. I don't think the J2ME app even builds today, without downloading 10 year old toolchains.

So OpenWIGLibrary is the only thing that you need.

[matejcik]

the wherigeooh branch is to support this guy, which ... well ... the cooperation was not great and I don't particularly care what happens to it. In any case you definitely don't need it.

[Lineflyer]

Thanks @matejcik for the detailed and helpful explanation.

I will leave the cleanup of the repo content to those working on the app itself. Those should feel free to provide according PRs.

the wherigeooh branch is to support this guy,

Interesting. Was it planned, that this guy sells it afterwards....Not a real question, no need to discuss it here.

Thanks once again for all your help.
Do you know any people with knowledge about OpenWIG besides yourself, who could help to continue it?

[bekuno]

@Lineflyer I miss the issues (and wiki) tab for the openwig repo.
Please activate this.

[Lineflyer]

@bekuno Done!

[Lineflyer]

Closing here as the new topics are now tracked in the issues of the new repo.