Github user afs commented on the issue:
https://github.com/apache/jena/pull/312
The difference between "humor" and "humour".
The only thing I though of cutting was `<reporting>` as we don't use it in
the build, given the long history of the codebase, none are really very useful
(or maintained to check the reports even work). They can be called separately
anyway.
The crux question is whether to have a simple, but mixed, POM structure vs
more modules for more POMs driven by maven requirements.
Delivery POMs `apache-jena-*` reflect that Jena is not necessarily one
tightly integrated "thing". If we go towards BOM and all that implies, we seem
to be saying it is more tightly integrated.
That suggests to me leaving it fluid like it is, because adding new modules
(contribution, code, not ones needed for maven design), with different
statuses, different users, is better. A choice of BOM structure seems to be
good for a project that is one thing.
So flexibility(future) vs separated concerns(now; assuming constant for the
future).
In an enterprise project, changing the POM design as needs change is
easier, because you can press the reset button, migrate and take the old
offline. An open source project, via central.maven, keeps the old around.
---
