On Thu, May 14, 2020 at 12:55 PM Michal Srb <m...@redhat.com> wrote: > 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. >
Long story short - IT world liked so much Java way of doing things so containers popped up so the same effect can be achieved for any language :P . > > 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 > -- Alexander Kurtakov Red Hat Eclipse Team
_______________________________________________ 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
