java-devel May 2012

java-devel@lists.fedoraproject.org

9 participants
6 discussions

Eclipse plugins questions
by Gerard Ryan 14 Jun '12

14 Jun '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, So, I haven't got much experience with building eclipse plugins, but that is changing quickly. For JBoss Tools, I need some additional parts of wtp, which I have been trying to do over the last few days. One problem I'm running into, is that some stuff that I need from there seems to depend on old versions of stuff that we have in fedora, and I don't know what to do in this situation. Example: I'm trying to build the feature org.eclipse.wst.ws_core.feature, in wtp-webservices. One of the plugins that this feature builds is org.eclipse.wst.wsdl.validation. This plugin depends on org.apache.xerces 2.8.0. In fedora, we've got 2.11.0. Somewhere between these two versions, some things changed, and the plugin is not fully compatible with the new version. See the following error: [javac] 6. ERROR in /home/grdryn/Downloads/jeetools-HEAD/ws3/plugins/org.eclipse.wst.wsdl.validation/src/org/eclipse/wst/wsdl/validation/internal/ValidationController.java (at line 311) [javac] public void reportError(String domain, String key, Object[] arguments, short severity) throws XNIException [javac] ^^^^ [javac] The return type is incompatible with XMLErrorReporter.reportError(String, String, Object[], short) If I comment org.eclipse.wst.wsdl.validation out of the feature, try to rebuild, there will be new errors, because other plugins depend on different versions of other stuff. What's the next step here? Here's a few possibilities rolling around my head, I'm not sure if any of them are right: - - package the older versions of deps for fedora. I'm pretty sure this isn't the answer. - - patch all of the files to fix the errors, and apply those patches in the fedora package. This doesn't feel right either, as there would be quite a large number of patches. - - submit patches upstream, wait until they are accepted, then package for fedora. This sounds the most right I think, but I've no idea if the patches will be accepted (upstream might be sticking to older deps for good reasons, so as not to break other stuff). I'm also under time constraints, as I'm packaging JBoss Tools as part of Google Summer of Code. Are any of these the right way to go about this, or are there other possibilities? - -- Gerard Ryan :: galileo(a)fedoraproject.org :: http://gerard.ryan.lt/blog PGP Fingerprint: AA11 A666 C98E B6D8 231C 11ED 6EDC 7E4A 62BC 4A15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPx8BpAAoJEG7cfkpivEoVgrQQAIH9tZ2K6BeK3a1uz/534vlq 0x74Ju+TcTu5SnRiv6omEhulN+JLoGIApHBgWIECWQ9C+Ho6wWNwmfClwfaj+MFq Mpvwl2LwG0wup4SpxPmt7otAH3gSCcKAHySfCtctmDGCebjYJ/QdR7aEQkJBYqcK AF1chYgOfYM819gNZpOsXtH4dukGrHMKhmyXCvRrCyxdxloNkvHKfaf67N14vX5g wBsPScNUDuuN/YtLnvpSJsuFd2/oEnh8FX60Ww07Art1K226+emiNYiQQjCLZfG2 C4Lm/Jb51wX14h/JLibJgRgrKD4m2JcppiyeSxHQOiQ4Qrr1zW1IryqEs+D8od7g jRgEzAp+UfagMWxtMqH1QxoKZT39avaVe4am39DluRhem9VH9sRCIMUYRIYtOJQQ mIQlFfSutlIWuWfijVwb6di3KUx+8K6EzyQFU70JOqMUxNPaaJPY1mYm8ptPpQM0 GsrWncz64/lAApSfu3KO+B/DrODjh56Tfb5t8vBk/lizTz/okKCVUK8Q5o3SsIIv IoGPEzJSYK6kuwadlBKNBEKZcFdE+2yI9KMnBB+mAIu8Au2DqODsQHxotLUPXMK5 5ZEKR1TIvBI6Z0SYGXa1WmcEQCCQRM90En7dDEjoWLeNqS26Z3RGVh9ayluFBcfu 2r7IVlRZqrNLt+J04KSp =UmtE -----END PGP SIGNATURE-----

2 5

Guacamole stack in Fedora
by Simone Caronni 05 Jun '12

05 Jun '12

Hello, following the mail in fedora-devel, I'm posting here some progress in packaging the Guacamole stack for Fedora. I hope to get some advice from Fedora Java gurus... A brief overview: Guacamole [1] is an HTML5 web application that provides access to desktop environments using remote desktop protocols such as VNC or RDP. A centralized server acts as a tunnel and proxy, allowing access to multiple desktops through a web browser. No plugins are needed: the client requires nothing more than a web browser supporting HTML5 and AJAX. Guacamole parts: Java: guacamole - The main web application, written in Java. guacamole-common - The Java API used by the web application. guacamole-common-js - The JavaScript library used by the web application. guacamole-ext - Common interfaces for extending the main web application. Native code: guacd - The proxy daemon which translates between remote desktop protocols and the Guacamole protocol. libguac - The common library used by all C components of Guacamole, including guacd and all protocol support plugins. libguac-client-vnc - VNC support for guacd. libguac-client-rdp - RDP support for guacd. At [2] you can find all the reviews that I have pending, all the native libraries and daemons are already under review; now I need to start creating reviews for the other java/maven based packages following instructions at [3] My first attempt is to package "guacamole-common" [4]; I think I have succeeded thus far. Since this is my first Java package for Fedora I need some advice on how to do things properly. Will someone be so kind to look at the package review at [5]? [1] http://guac-dev.org/ [2] https://fedoraproject.org/wiki/User:Slaanesh [3] https://fedoraproject.org/wiki/Packaging:Java [4] http://guac-dev.org/guacamole-common [5] https://bugzilla.redhat.com/show_bug.cgi?id=824798 Thanks, --Simone On 10 May 2012 17:30, Stanislav Ochotnicky <sochotnicky(a)redhat.com> wrote: > Quoting Tom Callaway (2012-05-10 16:06:44) >> You might want to ask in #fedora-java, those guys have quite a bit of >> experience with packaging Java bits with Maven. > > Yes, and at least one of them occasionally reads this list :-) > >> On 05/10/2012 08:57 AM, Simone Caronni wrote: >> > Added all dependencies, not before clashing mid air while applying them :D >> > >> > The daemon itself needs a client; documentation on how to write it are >> > on Guacamole web site. >> > >> > The Gucamole project provides its one Web Interface; and I have some >> > struggle packaging it. It is made of the following components: >> > >> > guacamole - The main web application, written in Java. >> > guacamole-common - The Java API used by the web application. >> > guacamole-common-js - The JavaScript library used by the web application. >> > guacamole-ext - Common interfaces for extending the main web application. >> > >> > All compile with maven and in the end they are packaged as a war file: >> > >> > http://guac-dev.org/guacamole >> > >> > I've seen many *-js packages in koji, but they all compile with ant; >> > here I need maven. >> > Can somone point me to some examples in Fedora on which I can rely to >> > build this stack? > > Well. For simple-ish examples of using Maven you can have a look at > apache-commons-io and related commons packages. They should be > relatively clean being updated only recently. > > To build Java stuff with Maven in fedora you have to use a bit modified > mvn-rpmbuild script that works in offline mode. Note that all > dependencies (even build-deps) will have to be packaged and properly > added to BuildRequires, otherwise the packages will not build. Quick > glance at the deps seemed to suggest we have them all so you should be > OK. I have to say I kind of like this project. Clear licensing, no > bundling, no shading. Way to go. You can high-five upstream if you are > in touch :-) > > There is one more issue: We don't have packaging guidelines for java > webapps. You might want to have a look into[1] and [2] where we > discussed it somewhat. We should get it over with one of these days. I > would propose putting the unpacked war file into /usr/share/webapps-java > and symlinking dependencies into lib subdir. Seems like the package is > self-contained so even "bundling" its parts in war might be OK here. > > If you've never packaged Java software for Fedora this might be a bit > confusing so feel free to stop by #fedora-java where we can help you out > in real-time. > > [1] http://dep.debian.net/deps/dep7/ > [2] http://meetbot.fedoraproject.org/fedora-meeting-1/2010-12-08/fedora-meeting… > > > -- > Stanislav Ochotnicky <sochotnicky(a)redhat.com> > Software Engineer - Base Operating Systems Brno > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.com > -- > packaging mailing list > packaging(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/packaging -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson).

2 6

Java Frameworks in Fedora?
by Frank Murphy 21 May '12

21 May '12

Hi, Did a yum search "java frameworks" (F16) came back with clojure.noarch Can the sig tell me if there any any packaged frameworks, that would be suitable for an interactive freemedia web-app. Before I go any further. -- Regards, Frank "Jack of all, fubars"

2 2

Flyer/Brochure for AS7 on Fedora
by Sarah White 17 May '12

17 May '12

Hi, I'm going to be attending UberConf[1] and JAX San Francisco[2] as a Fedora ambassador and Robyn suggested I create a brochure/brief sheet about using AS7 on Fedora for developers. Does anyone have any suggestions or ideas about what to say or show to developers that would convince them that using AS7 on Fedora is (yum)my? Or how Fedora as a java development environment is emerging? Any tips or tricks about using AS7 on Fedora or about java development on Fedora? Dan Allen (mojavelinux) will be presenting talks about AS7 at both conferences so it will be a good time to introduce the audiences to Fedora. Let me know if you have any ideas or suggestions. Cheers, Sarah White graphite6 [1] http://fedoraproject.org/wiki/UberConf_2012 [2] http://fedoraproject.org/wiki/Jax_US_2012

1 0

Handling of EE apis and other multiple implementations
by Stanislav Ochotnicky 17 May '12

17 May '12

Hi all, we have been having long-standing issues with multiple implementations of the same APIs (javax.servlet, javax.servlet.jsp, etc). Namely we don't handle them at all. They work in Maven through our dependency mapping, but are not really usable during runtime. What I mean is for example several packages requiring javax.servlet implementation, but in reality they have to pick one of several RPMs we have. This inevitably leads to bloated installations when users inevitably end up with more than one implementation installed (and their deps). There has always been a solution for this, which is using alternatives system[1]. We haven't used it, mostly because relatively complicated nature. So I went looking into simplifying it with rpm macros. Long story short...this didn't turn out well mostly due to different implementations needing different things on classpath. Ergo: I would like to propose a standardization on naming and use of java EE APIs. There are several aspects of this: 1. We need to chose 1 implementation to serve as "THE" implementation for each API. 2. That package will get to "Provides: EEAPI". Other packages can stop pretenting to provide any EE api :-) They can of course be used directly if a package requires something specific. 3. Since packages will be using "Requires: EEAPI" we can switch implementations easily if the need arises (dead project, new major version etc.) Now, I would like to standardize EEAPI naming as well. We have several versions of this. For example from tomcat.spec: Provides: jsp = %{jspspec} Provides: jsp22 ... # other package Provides: el_1_0_api = %{epoch}:%{version}-%{release} Provides: el_api = %{elspec} ... # other package Provides: servlet = %{servletspec} Provides: servlet6 Provides: servlet3 So it looks like we are not consistent and I would like to fix that. My first idea was to have: Provides: javax.xml ... %files %{_javadir}/javax.xml.jar # this is symlink Then I realized JSP is "javax.servlet.jsp", and Servlet API is a superset so first 2 parts of package name would not be enough there. We could still have: Provides: javax.servlet # in servlet impl and: Provides: javax.servlet.jsp # in jsp impl To be clear: I want the names to be simple to deduce without going through spec files, searching with yum (much) etc. The simpler the better. I would hope Java devs chime in here. What would be the first thing that came to your mind here? As for versioning APIs, I am not sure that would be needed. We usually try to keep packages up to date with latest APIs and packages not supporting current API can be moved to an older implementation. How does this sound to you all? [1] http://fedoraproject.org/wiki/Packaging:Alternatives -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

3 5

-javadoc subpackages require jpackage-utils
by Guido Grazioli 03 May '12

03 May '12

https://bugzilla.redhat.com/show_bug.cgi?id=723779 Are there any other reasons for requiring jpackage-utils on -javadoc subpkgs? I could not find anything specific in the java guidelines, except in the ant and maven templates. -- Guido Grazioli <guido.grazioli(a)gmail.com> Via Parri 11 48011 - Alfonsine (RA) (Italy) 3 Baltic Circuit - 3030 Point Cook - VIC (Australia) Mobile: +39 347 1017202 (10-18 GMT+12) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel May 2012