Reduce project size

[TimvdLippe]

The size of this project is quite huge at the moment. Several factors seem to be:

• ~2500 mvn dependency installs
• Usage of gitsubmodules instead of using a package manager
• Large Twemoji dependency of ~0.5GB

I think switching to a frontend package manager and possibly replacing twemoji can win a lot already. Also, are all mvn dependencies actually required? @LiamClark and I were already running in a huge spiderweb of incompatible transitive dependencies when upgrading 1 dependency. Seems that this will be a problem moving forward.

[LiamClark]

regarding the transitive dependencies problem with guava.

The biggest problem would be query-dsl. Even in their latest version they still depend on guava 18.0. So yes we are in a nasty situation regarding selenium. Any newer version than 3.0.0 will not work, but I'd rather not rewrite all our queries.

@JWGmeligMeyling you seemed to have some thoughts regarding a front end package manager.

[jwgmeligmeyling]

1. We should get rid of manually wiring all the versions of our dependencies together. We should use a Maven bom (Bill of Material) file, from for example WildFly or WildFly Swarm. Then we can get rid of most version numbers in our POM-file, and ensure that a particular version of Resteasy, Hibernate or Jackson is compatible with the other dependencies.
2. Cloning with depth=1 should reduce the size of the submodules.
3. Another branch with a newer version of QueryDSL is present so I have no problem merging that in. We can also use a shaded artifact to run guava 18 only for query-dsl, and have the rest of the application use guava 19.

I have a couple of projects where I run npm or yarn and gulp tasks through Maven, and that works pretty neat. I also had a branch for Devhub open for this (#172), which was eventually postponed because we wanted to keep the number of dev-dependencies down.

The problem is really that devhub-tud/devhub is only a quarter of the entire project. Before you get to run the entire package, you have to go through setting up Docker, Gitolite (or a Gitolite docker container), Docker CA certificates, etc. Setting all this up easily requires an entire day and I'd rather not spend another day installing all the JS stuff too. Particularly not on Windows computers. So I honestly think switching package managers - as much as I would want to - only makes sense when its a design decision requested by new maintainers that eventually have to work with it the most.

[LiamClark]

Even query dsl 4 depends on guava 18

[jwgmeligmeyling]

Lets track in https://github.com/devhub-tud/devhub/issues/477 and https://github.com/devhub-tud/devhub/issues/478