[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