Hiya,
It's been long time since I talked to you guys. There are many reasons for it, but most important one is that I was pulled to do some of the Docker work on the Middleware side and I simply had no time :/ Even worse, I do not see the end.
WildFly is in a pretty bad state now, sadly. New versions (8.2.0.Final and later 9.0.0.Final and of course 9.0.1.Final) are avialable since a while but it the package has not been updated. I did some work to make it happen:
https://bugzilla.redhat.com/show_bug.cgi?id=1181081
But then I was pulled back to the other work and it basically died.
The current status is a result mostly because of lack of my time, but also no joy with dealing with such a fragmetized beast. The single distribution was split into pieces and currently the WildFly depenency chain contains around 200 packages, whereas I'm alone maintaing about 130 of them (if you want to take a look at packages I maintain: https://admin.fedoraproject.org/pkgdb/packager/goldmann/). When I was working only on packaging of JBoss AS (and later WildFly) this was doable, but in current situation - I'm not able to maintain it anymore. It's really sad to see how this energy put into this effort is now dissapearing.
There are currently many bugs reported against my packages (WildFly deps), but I just don't have time to fix them making some people upset, which is of course not my intention. Gil is helpful as always sending some patches, but I don't even have time to look at them :( Basically - maintaining WildFly is a full time work for one person.
I need an advice from you guys how to proceed in a best way with this stuff, since I'm not closely following the Java world in Fedora anymore (sorry!) maybe I'm missing some obvious solutions.
Orphaning WildFly (and other packages) is the last thing I want to do, but I'll do it if we'll not find any solution.
So, here we are, let's talk!
--Marek
On this note, I prepared a COPR repo with latest stable WildFly:
https://copr.fedoraproject.org/coprs/goldmann/wildfly/
This is basically the Fedora spec with one, but big difference - I'm not building anything from source but just repacking the distribution.
It took 1 hour to adjust everything and set up the builds. Compared to the time I spent on the "proper" packaging (over one year) method this is like night and day.
--Marek
On Fri, 2015-08-07 at 11:13 +0200, Marek Goldmann wrote:
Hiya,
It's been long time since I talked to you guys. There are many reasons for it, but most important one is that I was pulled to do some of the Docker work on the Middleware side and I simply had no time :/ Even worse, I do not see the end.
WildFly is in a pretty bad state now, sadly. New versions (8.2.0.Final and later 9.0.0.Final and of course 9.0.1.Final) are avialable since a while but it the package has not been updated. I did some work to make it happen:
https://bugzilla.redhat.com/show_bug.cgi?id=1181081
But then I was pulled back to the other work and it basically died.
The current status is a result mostly because of lack of my time, but also no joy with dealing with such a fragmetized beast. The single distribution was split into pieces and currently the WildFly depenency chain contains around 200 packages, whereas I'm alone maintaing about 130 of them (if you want to take a look at packages I maintain: https://admin.fedoraproject.org/pkgdb/packager/goldmann/). When I was working only on packaging of JBoss AS (and later WildFly) this was doable, but in current situation - I'm not able to maintain it anymore. It's really sad to see how this energy put into this effort is now dissapearing.
There are currently many bugs reported against my packages (WildFly deps), but I just don't have time to fix them making some people upset, which is of course not my intention. Gil is helpful as always sending some patches, but I don't even have time to look at them :( Basically - maintaining WildFly is a full time work for one person.
I need an advice from you guys how to proceed in a best way with this stuff, since I'm not closely following the Java world in Fedora anymore (sorry!) maybe I'm missing some obvious solutions.
Orphaning WildFly (and other packages) is the last thing I want to do, but I'll do it if we'll not find any solution.
So, here we are, let's talk!
--Marek
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
We really need a tool that does "proper" packaging. Maybe extend xmvn with a rpm build extension? I'm completely ignorant of its current state though.
At the other end I think we need to change the module repository structure to be maven like. Or be able to consume a (local) maven repository/cache. The actual module.xml should still come from somewhere, but we should be able to load the bits in WildFly directly from however it is installed via the RPM.
I agree that right now the setup is not scale-able. :-)
Tried it though: Exception in thread "main" java.lang.CloneNotSupportedException: Marek at java.lang.Object.clone(Native Method)
:-D
Carlo
On 08/11/2015 12:47 PM, Marek Goldmann wrote:
On this note, I prepared a COPR repo with latest stable WildFly:
https://copr.fedoraproject.org/coprs/goldmann/wildfly/
This is basically the Fedora spec with one, but big difference - I'm not building anything from source but just repacking the distribution.
It took 1 hour to adjust everything and set up the builds. Compared to the time I spent on the "proper" packaging (over one year) method this is like night and day.
--Marek
On Fri, 2015-08-07 at 11:13 +0200, Marek Goldmann wrote:
Hiya,
It's been long time since I talked to you guys. There are many reasons for it, but most important one is that I was pulled to do some of the Docker work on the Middleware side and I simply had no time :/ Even worse, I do not see the end.
WildFly is in a pretty bad state now, sadly. New versions (8.2.0.Final and later 9.0.0.Final and of course 9.0.1.Final) are avialable since a while but it the package has not been updated. I did some work to make it happen:
https://bugzilla.redhat.com/show_bug.cgi?id=1181081
But then I was pulled back to the other work and it basically died.
The current status is a result mostly because of lack of my time, but also no joy with dealing with such a fragmetized beast. The single distribution was split into pieces and currently the WildFly depenency chain contains around 200 packages, whereas I'm alone maintaing about 130 of them (if you want to take a look at packages I maintain: https://admin.fedoraproject.org/pkgdb/packager/goldmann/). When I was working only on packaging of JBoss AS (and later WildFly) this was doable, but in current situation - I'm not able to maintain it anymore. It's really sad to see how this energy put into this effort is now dissapearing.
There are currently many bugs reported against my packages (WildFly deps), but I just don't have time to fix them making some people upset, which is of course not my intention. Gil is helpful as always sending some patches, but I don't even have time to look at them :( Basically - maintaining WildFly is a full time work for one person.
I need an advice from you guys how to proceed in a best way with this stuff, since I'm not closely following the Java world in Fedora anymore (sorry!) maybe I'm missing some obvious solutions.
Orphaning WildFly (and other packages) is the last thing I want to do, but I'll do it if we'll not find any solution.
So, here we are, let's talk!
--Marek
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
Hey,
Do we really need to insist java applications like WildFly and Eclipse are fully decomposed down to individual RPM's ?
Could it not be sufficient (and easier) to just have one big RPM for this ?
Meaning, sure - need to find source and rebuild to check origin but don't need to keep coordinating dependency jar updates *unless* there is a known security issue for a jar included ?
just thinking out aloud.
/max
Hiya,
It's been long time since I talked to you guys. There are many reasons for it, but most important one is that I was pulled to do some of the Docker work on the Middleware side and I simply had no time :/ Even worse, I do not see the end.
WildFly is in a pretty bad state now, sadly. New versions (8.2.0.Final and later 9.0.0.Final and of course 9.0.1.Final) are avialable since a while but it the package has not been updated. I did some work to make it happen:
https://bugzilla.redhat.com/show_bug.cgi?id=1181081
But then I was pulled back to the other work and it basically died.
The current status is a result mostly because of lack of my time, but also no joy with dealing with such a fragmetized beast. The single distribution was split into pieces and currently the WildFly depenency chain contains around 200 packages, whereas I'm alone maintaing about 130 of them (if you want to take a look at packages I maintain: https://admin.fedoraproject.org/pkgdb/packager/goldmann/). When I was working only on packaging of JBoss AS (and later WildFly) this was doable, but in current situation - I'm not able to maintain it anymore. It's really sad to see how this energy put into this effort is now dissapearing.
There are currently many bugs reported against my packages (WildFly deps), but I just don't have time to fix them making some people upset, which is of course not my intention. Gil is helpful as always sending some patches, but I don't even have time to look at them :( Basically
maintaining WildFly is a full time work for one person.
I need an advice from you guys how to proceed in a best way with this stuff, since I'm not closely following the Java world in Fedora anymore (sorry!) maybe I'm missing some obvious solutions.
Orphaning WildFly (and other packages) is the last thing I want to do, but I'll do it if we'll not find any solution.
So, here we are, let's talk!
--Marek
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
Inline.
On Mon, 2015-08-24 at 15:00 +0200, Max Rydahl Andersen wrote:
Hey,
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.
--Marek
Meaning, sure - need to find source and rebuild to check origin but don't need to keep coordinating dependency jar updates *unless* there is a known security issue for a jar included ?
just thinking out aloud.
/max
Hiya,
It's been long time since I talked to you guys. There are many reasons for it, but most important one is that I was pulled to do some of the Docker work on the Middleware side and I simply had no time :/ Even worse, I do not see the end.
WildFly is in a pretty bad state now, sadly. New versions (8.2.0.Final and later 9.0.0.Final and of course 9.0.1.Final) are avialable since a while but it the package has not been updated. I did some work to make it happen:
https://bugzilla.redhat.com/show_bug.cgi?id=1181081
But then I was pulled back to the other work and it basically died.
The current status is a result mostly because of lack of my time, but also no joy with dealing with such a fragmetized beast. The single distribution was split into pieces and currently the WildFly depenency chain contains around 200 packages, whereas I'm alone maintaing about 130 of them (if you want to take a look at packages I maintain: https://admin.fedoraproject.org/pkgdb/packager/goldmann/). When I was working only on packaging of JBoss AS (and later WildFly) this was doable, but in current situation - I'm not able to maintain it anymore. It's really sad to see how this energy put into this effort is now dissapearing.
There are currently many bugs reported against my packages (WildFly deps), but I just don't have time to fix them making some people upset, which is of course not my intention. Gil is helpful as always sending some patches, but I don't even have time to look at them :( Basically
maintaining WildFly is a full time work for one person.
I need an advice from you guys how to proceed in a best way with this stuff, since I'm not closely following the Java world in Fedora anymore (sorry!) maybe I'm missing some obvious solutions.
Orphaning WildFly (and other packages) is the last thing I want to do, but I'll do it if we'll not find any solution.
So, here we are, let's talk!
--Marek
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
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 ? :)
java-devel@lists.fedoraproject.org
-
Carlo de Wolf -
Marek Goldmann -
Max Rydahl Andersen