Peter Boy wrote:
A valid point, but only in case the app that consumes the maven
artefact
in unmaintained.
Many applications are maintained and never (or very rarely, only when they
encounter some issue with the version they currently use) bother bumping
their dependencies after adding them once. Especially in the corporate
world, this is commonplace.
I wrote:
> So you propose to bundle a whole bunch of JARs, some of which
have been
> built many Fedora releases ago and might not even be buildable in any
> currently supported Fedora anymore?
and Peter Boy replied:
No! See above.
Yet, that is exactly what "Once a JAR is built, the resulting bytecode will
work with current and future JVMs. There is no need to mass-rebuild JARs
every 6 months." (Michal Srb) implies.
> I think this would be not only a huge
> waste of space
given the current size of hard drive space, this really isn't a problem.
You won't be able to install a meaningful collection of apps whose
cumulative footprint of jars installed in parallel leaves any noticeable
trace on a x tb disk.
Considering that Fedora now also targets devices with as little as 16 or 32
GB out-of-the-box storage:
https://fedoraproject.org/wiki/Architectures/ARM/PinePhone
https://wiki.pine64.org/index.php/PinePhone#Specifications
that argument is invalid.
But you gain a lot in security if as many of these
apps as possible are managed as rpm.
Sure, a bunch of JARs in an RPM is marginally better than a bunch of JARs in
a tarball. But it is no replacement for real packaging with unbundling.
Kevin Kofler