Hi,
java-deptools is a project that can extract class information from RPM
packages. It has been provided as a commandline tool and now I'm working
on bringing it online as a web service. The web service can search for
class names and tell you in which RPMs the classes exists in Fedora. It
is now available in Fedora Cloud at:
http://java-deptools.fedorainfracloud.org/
Currently, it can only be used for searching for class names in Fedora
Rawhide, but there are plans for more. Please keep in mind that the
current instance is experimental and may not be reliable (the database
is currently regenerated manually). Ideas for features/contributions are
welcome.
Source repository is at: https://github.com/msimacek/java-deptools
Michael Simacek
Forwarding, if someone can help Terje with this one.
Alexander Kurtakov
Red Hat Eclipse team
----- Forwarded Message -----
From: "Terje Røsten" <terje.rosten(a)ntnu.no>
To: "Alexander Kurtakov" <akurtako(a)redhat.com>
Sent: Saturday, 29 August, 2015 1:45:56 PM
Subject: Fedora: Issue with ditaa after batik 1.8 update in rawhide
Hi!
After update to batik 1.8, ditaa no longer builds.
I am maintainer for ditaa in Fedora, however no Java expert, reported
issue upstream:
https://github.com/stathissideris/ditaa/issues/12
No response yet.
Is this easy for a Java developer to fix?
Cheers,
- Terje
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
Hi,
I have had no experience at all with java or java packaging, but I am
trying to package Vash[0] in order to unbundle it from Winswitch[1].
Unfortunately Vash doesn't ship with any kind of usable buildsystem
info. I've tried the dumb thing of running javac over each file in
turn, but that just spews errors. Any help would be very gratefully
received!
Thanks,
Jonathan.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1250198
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1243530