POM clean up

[bertfrees]

Because the POM has been growing incrementally and different people have worked on it, it has become a bit of a mess. There are a number of problems:

• The POM is used to selectively build a variety of artifacts that share certain build tasks. Unfortunately Maven is very bad at this. (Ant or Make handle these cases much better.) We try to solve it with a number of Maven features/hacks, but there is no single strategy. For example some profiles explicitly depend on other profiles using maven-enforcer-plugin (e.g. the docker profile depends on deb profile), other profiles also depend on other but do not enforce this (e.g. the installer profile depends on the webui profile). Some profiles disable certain parts of the build (e.g. the deb profile disables the ZIP artifacts, i.e. dist-mac, dist-linux and dist-win). Sometimes a dependency is worked around by duplicating things (e.g. the deb profile and the webui profile both download the webui jar).
• Inconsistent profile granularity. The RPM build has separate profiles for server, cli and webui. The DEB build has just a single profile. The ZIP build has separate profiles for Linux, Mac and Windows
  The webui profile builds them all at once.
• The naming (e.g. profiles) is maybe not always consistent.

Ideally we should be able to selectively build any part of the software (server, CLI, web UI, GUI), for any platform (Windows, Mac OS, Linux), and with any packaging (ZIP, DEB, RPM, installer, Docker image?), without having too much duplication.

[rdeltour]

I agree, pretty good summary of the current situation. Although I don't have a clear idea of a concrete approach to improve it (I've thought about it too long).
I suppose we're reaching the limits of Maven. Gradle would probably be more flexible here, but we s/b careful about adding another skillset requirement.

[bertfrees]

Yes maybe trying to achieve this ultimate goal with Maven is just not possible.

If Gradle is really better at handling these things, we should keep it in mind. Things are still manageable now but maybe there comes a day when the move is really worth it. This might be interesting: http://gradle.org/docs/current/userguide/build_init_plugin.html

[bertfrees]

This subject came up again this week at our face-to-face meeting in Stockholm. Because the Pipeline is currently undermaintained we've agreed on a strategy to make it as easy as possible for organisations to take things into their own hands. Waiting for official releases that come once a year is simply not an option for most organisations, so it is recommended for them to fork the assembly project (and possibly other), to use their fork for their local deployments, and to make PRs from time to time to get their contributions upstream. A consequence of this is that it should be easy for organisations to customize and maintain a fork, and for us to merge things back.

[bertfrees]

I've done some more thinking and experimenting and I think what we should do is the following.

Moving to Gradle would be too much work I think and would require a whole new approach because Gradle doesn't have the concept of BOMs.

The easiest solution I think is to split up the POM in as many profiles as required so that there isn't any duplication anymore, and a profile doesn't do too much for a certain task. Selecting the right list of profiles for a certain target will then be done in a wrapper script (initially a Makefile, but we should have something that works on Windows eventually), to keep it usable.

[bertfrees]

See also #138