On Mon, Jan 27, 2020 at 1:44 PM Mario Torre <neugens@xxxxxxxxxx> wrote: > > On Mon, Jan 27, 2020 at 7:11 PM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > > > Java packaging being extremely difficult is not a Fedora-specific > > problem. The modularity effects are, but the packaging has been > > known-hard for a very long time in many distros (and even outside a > > distro context, it's not fun to work with the Java package managers). > > Distribution of java libraries and sometime applications is a problem > that the Java community has solved (arguably with mixed results and > not completely) with the use of maven, and most of the de-facto > standard solutions evolve around some use of maven for deployment and > shipping of the dependencies required to run and build end > applications. > > Fedora, for some reason that may have been understandable 15 years ago > but that clearly show the sign of time and the drawbacks decided to go > through a different form of distribution and instead of embracing > maven as a native tool for java packages has wrapped everything around > RPM, because this was how the rest was distributed. Of course, this > made sense as I said, you want to have one way central way and one > tool with one familiar interface to build up your distribution and OS, > but in hindsight I can't help thinking that it would have been better > to teach RPM about maven instead, after all xmvn is just an hack to do > exactly that. > > There are a few things that can be done to improve this situation > going forward, some of those ideas may include things like dropping > RPM packages completely, use flatpaks, create a properly audited > deployment channel similar to what maven central does but more > controlled and closed world, etc... > Honestly, the correct thing is to make it so the maven to RPM interface is as transparent as possible. We've done a reasonably good job with this in Rust, Ruby, and Python, and the situation is (slowly) improving in Go. But nobody has sat down and looked at what we have in RPM today and taken a fresh look at how Java packaging *could* work. I think you underestimate the value of having Java components shipped as RPMs, but I'm not surprised, as you've probably never had to actually be forced to audit the usage of Java components in various applications and justify them. It's a lot easier to do when the components are de-duplicated and used in a meaningfully uniform manner. Also, RPM distribution is loads easier than dealing with the disaster that is private Maven repositories. Riffing off what Florian had for his DevConf.cz talk title, JPackage/RPM Java is basically packaging like it's 1999. The rest of the ecosystems are moving forward. Java has not. And I think that's where a lot of the pain exists. But without interest or investment from the Java stack packagers at Red Hat, there's basically no way to get a redesign of Java packaging done, much less even on the table. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
