[fedora-java] WildFly status (and future) in Fedora

Max Rydahl Andersen manderse at redhat.com
Mon Aug 24 18:46:35 UTC 2015


>> Do we really need to insist java applications like WildFly and 
>> Eclipse
>> are fully
>> decomposed down to individual RPM's ?
>
> I understand very well reasoning from both sides. Decomposing makes it
> easier to track packages that need to be updated (CVE's) because the
> idea is to have only one place in the system where you need to patch. 
> On
> the other hand - different projects have different schedules and
> requirements, so managing all of them to use a specific version of a
> specific libbrary is very hard, it's time soncuming and sometimes
> impossible. This leads to frustration and to escape from the
> packaging/maintining work. I'm currently in that phase.

>>
>> Could it not be sufficient (and easier) to just have one big RPM for
>> this ?
>
> Basically you're talking about this (I announced it some time ago in
> this thread):
>
> https://copr.fedoraproject.org/coprs/goldmann/wildfly/
>
> This is still a valid RPM, but it's not built in the Fedora way.

More talking in the middle - drop the need for individual synced rpm's 
of each jar,
but still track which rpm's contain what jars/sub-rpms so CVE's etc. can 
be handled.

The Copr won't make it into any fedora repo, but yes, its surely the 
simplest way.

Isn't a lot of this done by EAP prod team anyway, can't that work be 
reused/shared to
avoid it all hang on one person  ? :)

/max
http://about.me/maxandersen


More information about the java-devel mailing list