use git submodules instead of copying dependencies

[sgeisler]

Imo the project structure would be cleaner if dependencies weren't just copied into the git repo but linked as git submodules. Updates of dependencies would not produce large changes since only the references get updated.

The only downside of this is that people need to clone recursively git clone --recursive <repo> which is slightly uncommon and could lead to irritations if people forget to add the --recursive flag.

[haiqu]

Can you give an example of the type of dependencies you're talking about, and how often they're updated? The only one I can think of currently is Java itself, and after the current bugs are ironed out in the next version and the patches are removed I can't see a need to ever change it again.

[sgeisler]

I'm talking about all modules which seemingly just got copied into this git repo from other repos, like:

• jsocks
• jtorctl
• jtorproxy

if you update these dependencies you will have to replace these directories and produce a big diff. With submodules you could just "link" to another version.

[haiqu]

Manfred, are we likely to change those?

[sgeisler]

It's not just about changing versions, it's also about a clean structure. I see that it isn't that urgent, but in the long run you want to decouple your project from it's dependencies.

If you want to see how submodules look like you can have a look at my project LogSim. You will see that I linked the project nlohmann/json at commit 0a81353. Once you clone it recursively you will be able to work with it like a directory (I include a header file from this project).

[haiqu]

OK. Help me to understand this a bit better. If we do that, will a git pull also update dependencies? Because if that's the case we will end up with myriad variables in the build, which would be a Bad Thing(tm).

[sgeisler]

No, that's not how it works. Submodules are a link to a specific version of some git repository, they won't update automatically. You can update submodules as described in this StackOverflow answer.

We might want to have a fork of the linked repos in our organization namespace. This would keep our project intact no matter what happens to the original repo (deleting/force pushing). So for updating the submodule we would first pull all changes into the bitsquare forked repo and after that update the submodule.

[haiqu]

OK, sounds sensible to me.

[ManfredKarrer]

@sgeisler : Ah I also though you mean all modules. Those modules copied from other projects are definitely good to use as submodules. It would be also more clear to new devs that those are not core Bitsquare code base. We could even use just libraries of those, so compilation would be a bit faster (at first time, then its cached).
I just don't have time soon to work on that myself.

[haiqu]

Manfred, if I add a lib subdirectory and put the prebuilt jar files in there would you be happy with that solution? I can do it today.

[sgeisler]

Please don't do this, pre built ‎binaries are really hard to audit. Furthermore it would be just a superficial improvement, since they would still be in the project.

[ManfredKarrer]

Good point. Will use the sub module approach as soon I find time for it.

[haiqu]

OK. It was harder to do than I anticipated anyhow, due to the need to convince Maven to distribute to the correct place from a local repo. I'll leave it for now.

[haiqu]

I tried setting this up but it's really messy. jtorproxy relies on jsocks and jtorctl as submodules and pulls them in again. Since none of these projects have been worked on for many years I think we should dump the whole idea of adding them as submodules.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant.