On Thu, Sep 10, 2020 at 10:11 AM Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote: > > > > On Thu, Sep 10, 2020 at 4:46 PM Alexander Scheel <ascheel@xxxxxxxxxx> wrote: >> >> Hi Joe, >> >> On Thu, Sep 10, 2020 at 8:52 AM Joe Orton <jorton@xxxxxxxxxx> wrote: >> > >> > Hi all, >> > >> > I'm writing as the Red Hat engineering manager responsible for Maven and >> > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my >> > team. I want to give a broad response to some of the points here: >> > >> > 1. The team has two missions in Fedora: >> > >> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is >> > to provide developers with the most popular Java build systems which are >> > reviewed, tested, and updated through the release lifecycle. >> > >> > b) We design, develop and document tooling that enables anyone to >> > package Java software with a simple, efficient and scalable process. We >> > are also active members of Java SIG, collaborating on complex changes >> > and guiding new contributors. >> > >> > 2. We are committed to maintaining the Ant and Maven modules in >> > Fedora. We have always expected to make them available as default >> > streams and in the buildroot so they can be available and consumed by >> > non-modular packages, but we completely respect the decisions of FESCo >> > to disallow default streams and of other contributors to adopt and >> > maintain the non-modular packages. We are not going to promise to >> > commit time and resources to maintain the non-modular packages. >> >> As a reminder (as in my RHEL devel-list reply): there are no default >> module streams in Fedora. There is also no Ursa Major/Prime, so were >> they to exist, there would still be no way for non-modular packages to >> use them. >> >> This makes the artifacts produced here useful only to other modules. >> Non-modular packages maintained by other Red Hatters, like Eclipse and >> Dogtag PKI cannot use these artifacts. Both of these stacks have tried >> to modularize in Fedora but ultimately remained non-modular. > > > FWIW, I'm eagerly looking to stop packaging Eclipse as RPM entirely. Flatpak is way better suited for our use case and in addition gives us access to a way bigger install base. And the involvement on Java packaging in Fedora is so low that we literally have to maintain whole other stacks including jetty, lucene and etc. - not feasible work in any way. Mat Booth (also from the Eclipse team!) still actively helps out with this packaging as RPMs and we thank him for his efforts while they last. :-) But Flatpak isn't suitable for everyone--it isn't great for servers like Dogtag and IdM for instance. So we still need RPM packaging around for that. Also, does that mean Eclipse won't be in RHEL-9? So far it looks like it is not rebuilt for ELN so it seems likely it won't be. https://koji.fedoraproject.org/koji/packageinfo?packageID=183 - Alex > >> >> >> > 3. Our efforts are currently directed mainly at minimization of the >> > dependency tree which leads to maven and ant, automating the process of >> > bootstrapping maven and updating related components, so that new >> > versions can be imported and built reproducibly and with consistent >> > quality. >> > >> > 4. The benefit we want to preserve from modules is to maintain packages >> > with varying expectation of quality, specifically separating the >> > build-time-only vs runtime dependencies. e.g. in that case that a web >> > server like Eclipse Jetty is required as a dep for testing another >> > component during the build, we want to be able to use and build that >> > component, without being indefinitely on the hook for security errata. >> > (The build dependency tree is particularly complex for Maven and >> > involves many examples of packages with frequent and high severity >> > vulnerabilies) >> > >> > Regards, Joe >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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 > > > > -- > Alexander Kurtakov > Red Hat Eclipse Team > _______________________________________________ > 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 _______________________________________________ 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
