Re: What's the State of the Java SIG?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message -----
> From: "Mikolaj Izdebski" <mizdebsk@xxxxxxxxxx>
> To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Cc: "java-devel" <java-devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Monday, November 18, 2019 5:42:20 AM
> Subject: Re: What's the State of the Java SIG?

~snip~

> Maintenance of obsolete packages is non-goal for Java SIG.

A number of packages -- which the Java SIG has dropped -- are still
under active development. The Apache Commons collection, JBoss packages,
glassfish/jakarata/... packages, plexus, &c. Sure, we have a few dead
packages. We've tried our best to drop many of these. And admittedly we're
still on the JavaEE packages pre-Eclipse donation (and rename to Jakarata).
But calling these large package collections maintained by three large,
active maintainer bases (Apache Foundation, Red Hat JBoss, and the Eclipse
Foundation) unmaintained seems... wrong?

~snip~

> > Or is it time for a "tabula rasa" and restart the SIG?
> >
> > I really hope we can get something off the ground, soon - because I
> > and other members of the Stewardship SIG have been spending a lot of
> > hours each week on keeping this stuff working, but my patience and
> > energy are reaching their limits. I'd really like to slowly start
> > handing over Java packages to someone who's actually using them, and
> > is interested in keeping them maintained.
> 
> IMHO effort spent on maintenance of most of these ursine Java packages
> is mostly wasted effort. As I said before, many times, these packages
> should be retired and replaced by modular packages, which are
> maintained by Java SIG members like me. maven and ant modules are
> already default streams, so users should get them instead of ursine
> packages. The last remaining step is enabling javapackages-tools in
> ursine buildroot so that ursine packages can be built with modular
> maven. Once that happens, there will be no reason to maintain ursine.
> Therefore, instead of putting time on updating ursine Maven et al.
> I recommend to put effort towards enabling modules in ursine buildroots.
> 
> > PS, side note about Modularity: If I understand the current state of
> > things correctly, the plan is to make the "maven:3.5" and "ant:1.10"
> > modular packages be installable alongside non-modular Java packages.
> > They're currently shadowing non-modular packages (since they have
> > default streams), but I understand this is getting fixed. This means
> 
> Shadowing of ursine packages by modular packages is not a defect.
> That is a feature of modularity. Therefore there is nothing to fix there.

I'm sorry Mikolaj, but I'm really confused reading this part of your mail.

A number of these packages exist as ursine packages precisely because
you've made them BUILDROOT-only! We, the Dogtag team, asked you to
reconsider that choice because we needed these as runtime dependencies,
not build-time only. You declined and said our choices were to maintain
our own modular forks or maintain the ursine variety. So, here we are.
And now, you're telling us to switch to modules? But that doesn't help
us access those BUILDROOT-only packages at runtime!


Could you help me understand how we're supposed to move forward?

- Alex
_______________________________________________
java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to java-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/java-devel@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Red Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux