Hi Joe, On Thu, Sep 10, 2020 at 8:52 AM Joe Orton <jor...@redhat.com> 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. > 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@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
