[WIP] Cleanup build script

[florian-beetz]

This prepares for splitting JabRef into several modules.

The dependencies were extracted to a separate file. This makes it much easier in the future to define shared dependencies across multiple modules, without duplicating them in the build scripts and especially keeping them all updated to the same version.

According to Gradle's guide on writing maintainable build scripts, build scripts should not contain any imperative logic but just declarative language elements. Imperative logic should live as plugins in the buildSrc directory. So I extracted the ANTLR tasks to this directory. This also makes it much easier to move the tasks to another module in the future.

What do you think? I would like to extract the XJC-, release-, and localization-tasks to separate plugins if you approve these changes.

---

• Change in CHANGELOG.md described
• Tests created for changes
• Manually tested changed features in running JabRef
• Screenshots added in PR description (for bigger UI changes)
• Ensured that the git commit message is a good one
• Check documentation status (Issue created for outdated help page at help.jabref.org?)

[Siedlerchr]

Isn't this now duplicated?

[florian-beetz]

This specifies the repositories used for resolving dependencies for the buildSrc project.
As far as I know, this does not overwrite or duplicate the buildscript.repositories property in the build.gradle.

[Siedlerchr]

I like the idea. How does that work with the multi module building?

[florian-beetz]

@Siedlerchr The buildSrc code is put on the classpath of the build scripts by gradle, including sub-modules. So in those sub-modules, you can just import static Dependencies.libraries and use them as in the main script. Same goes for the tasks I defined.

The main advantage of this is that the versions of dependencies don't need to be managed in every module, but you can just change the version in one central file and all modules will use that version.

[stefan-kolb]

The plugin idea looks good to me.
I'm not sure about the dependency extraction yet.
Will we have a lot of shared dependencies?
If we have modules for gui, logic, model, most libraries will not be shared between the projects except for test libraries?

[stefan-kolb]

Move comment to library file?

[stefan-kolb]

Comment to library file

[stefan-kolb]

Do we need this if it's empty?

[florian-beetz]

@stefan-kolb I agree that the dependency extraction is not optimal. I think something like mavens dependencyManagement would be much better, but afaik Gradle has no such thing.

As far as I can tell, shared dependencies are mainly testing, logging, guava, and antlr.
I guess when JDK 11 is released without JavaFX, it will become a shared dependency as well because the collections are used basically everywhere.

[stefan-kolb]

The question is, if we should just include the plugin idea for now and duplicate the dependencies.
After the module split, we could evaluate if it is reasonable to extract the dependencies (of course we should keep the code you wrote anyway).
I'm not sure which way to go.

[florian-beetz]

Sure, we can do that.

Just for completeness sake: I've read about two other possibilities to manage dependency versions in multi-module gradle builds.
One managed the versions in a gradle.properties like versionGuava=25.1-jre, and kept the dependencies in the build scripts but making the versions variable like compile "com.google.guava:guava:${versionGuava}".
The other is using this gradle plugin together with a Maven BOM, but IMO using the Maven XML with Gradle is pretty ugly.

[stefan-kolb]

Using a properties file looks promising to me.
This also would separate code and version declarations pretty well.
But maybe we just wait and see how the modules affect the build files in terms of duplication.

[tobiasdiez]

The extraction of plugins is definitely a good idea.
In principle, I also like the refactored dependencies except that it is now relatively complex to add a new dependency: you have to add an entry under version, under libraries and in the main gradle file. What do you think about combining the version and libraries lists, i.e. define the libraries in the usual full gradle format like org.apache.logging.log4j:log4j-core:2.11.0. Then adding a new dependency is still straightforward but you also have the advantage to reuse it in other modules. I know, you have some duplication of version strings but I don't think this is a big problem.

[florian-beetz]

@tobiasdiez Yes, I think now with the versions inlined it is a bit less confusing.

[tobiasdiez]

We discussed this in the dev call, and the decision was to include the changes of the plugins (done in #4934) and to wait with the extraction of the dependencies until we have a bit more experience with the modular build.

Thanks for your PR.