Hello,

On Tue, May 12, 2020 at 12:57 PM Felix Schwarz <fschw...@fedoraproject.org>
wrote:

>
> Am 12.05.20 um 12:32 schrieb Ty Young:
> > Right, I figured it was some Fedora policy and not up to you. I suppose I
> > should have been more clear there. Sorry for any confusion, it was aimed
> at
> > the Fedora project as a whole as this is a Fedora issue.
>
> This is not a Fedora issue but a consequence of Fedora's core values. You
> not
> agree with it but "building from source" is so fundamental that it does not
> make sense to even start a discussion about it on fedora-devel.
>
> I suggest you read up on the rationale behind that policy (which is why I
> linked the policy document in the first place).
>

I agree that building from sources is the right thing to do. However, let
me play devil's advocate here :)

What makes Java apps different from other language ecosystems is that Java
apps never share dependencies. There is no concept of "system-wide"
3rd-party Java libraries that would be automatically added to classpath
when JVM starts. I realize that this is technically possible to achieve,
but that is not how people use it. If you want to distribute your Java app,
you just bundle it with all its dependencies into a beefy tarball and ship
it.
And if Java apps never share dependencies, then developers are not really
forced to keep up with latest versions of libraries. Nobody can update the
non-existent system-wide Java library that would break their application.
They are in control.

Since there is no standard place for shared Java libraries on your laptop,
how can you use the packaged Java libraries and develop software against
them? Sure, you can hack it and make it work on your Fedora 32 machine, but
your custom Makefile is not guaranteed to work on Fedora 31 or later on 33.
And your colleague that is on CentOS is out of luck of course. And so are
all your potential external contributors on their MacBooks and Ubuntus.
What I am trying to say in this paragraph is that shipping (in RPMs) and
maintaining individual build-only Java libraries is, at least in my
opinion, questionable.

Fedora and other linux distributions are trying to do the right thing, but
things like Java apps simply don't fit in. What Java app developers are
doing may not be the best thing, but it's been like that for ~20 years, and
it seems to be "good enough" for the majority of people involved (well,
developers at least).
Fedora alone is too insignificant to change it I am afraid.

However, with all that being said. I do like "dnf install my-java-app"
better than unpacking some tarballs somewhere.

And finally, here comes the "devil's advocate" part of my email.

* building Java libraries and apps from sources?
  * +1, no doubt about this
* building Java libraries and apps from sources in a controlled and
reproducible environment?
  * yes, please
* building Java libraries and apps from sources from SRPMs?
  * do we really need the RPM overhead here?
* shipping (in RPMs) and maintaining Java libraries that are not runtime
dependencies of Java applications that we want to have in Fedora?
  * nope, why? build such build-only dependencies from sources, make sure
they are OK license-wise, but do not ship them to users (as explained
above, they are not very useful for developers anyway)

We can do license reviews, we can build from sources, but we don't
necessarily have to do all this in RPMs.
We can do all the right things, store (our binary) results in a
language-native way, which would be a Maven repository controlled by Fedora
in this case, and then simply wrap our good binary JARs into RPMs, without
rebuilding them all the time.

Note having such language-native repository full of good and reviewed Java
libraries would mean that developers that care about such things could
actually start using it instead of the official Maven repository. And they
wouldn't be tied to a specific version of Fedora or Linux.

I don't think this would go against the current packaging policy, it just
would be *a ton" of work :)

This email turned out to be way longer than I expected it to be, but Java
packaging is a complicated topic.

Thanks,
Michal


>
> I understand that missing components/features due to the source requirement
> are annoying but Fedora (and other distros) decided to take the "high road"
> here and actually fix stuff instead of shipping whatever upstream came up
> with.
>
> Felix
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to