java-devel June 2012

java-devel@lists.fedoraproject.org

10 participants
9 discussions

Chosing implementations for EE APIs and finalizing guidelines
by Stanislav Ochotnicky 05 Jul '12

05 Jul '12

With new additions to packaging guidelines for EE APIs, we have to pick 1 implementation for each API. I have made initial proposal for these APIs into the draft[1]. My criterias: 1. if JDK provides it, we are done. Packages should remove this dependency from pom.xml files 2. Prefer packages with smaller and simpler BR/R chains. Good example being javax.servlet.jsp where I preferred glassfish-jsp over tomcat or other implementations. 3. Exception for 2nd point: if the project is proven to be difficult in the past, override. Example being geronimo projects which were overriden few times. Even when we finalize this list, I don't expect it to be set in stone. I want it in the guidelines, but if situation arises where quick change is needed we can still do it. Longer-term, I'd like to package more simple independent implementations such as glassfish-jsp so we don't have dependency for example on tomcat in very basic dependency chain. Now, I'd like to give everyone time to look at my picks and poke holes in them. If you don't like them...speak up. If you don't, you will not have my sympathies later. So I'll wait a week for comments. I plan to finalize new guidelines by the end of next week. Then call SIG meeting (finally) and vote on it before presenting it to the FPC. [1] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#EE_A… -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

4 3

JBoss AS 7 packaging effort update
by Marek Goldmann 03 Jul '12

03 Jul '12

Hi all, If you're interested in JBoss Application Server I'm forwarding the current status of the packaging effort. --Marek -------- Original Message -------- Subject: [jboss-rpm] jboss-as is alive and on the road to next update Date: Wed, 27 Jun 2012 10:23:01 +0200 From: Marek Goldmann <mgoldman(a)redhat.com> To: jboss-rpm(a)lists.jboss.org <jboss-rpm(a)lists.jboss.org> Hi, You may be wondering what's happening in the jboss-as package world :) I know I haven't updated you since some time, but finally there is a bunch of news! I'm working on jboss-as-7.1.1-4. This will be a pretty big update, a lot of new subsystems will be enabled and the way I work on the spec will be changed. 1. New subsystems. Compared to 7.1.1-3, following new subsystems will be enabled: - org.jboss.as.arquillian - org.jboss.as.osgi - org.jboss.as.configadmin - org.jboss.as.spec-api As you can see, 7.1.1-4 is focusing on OSGi stuff. This involved packaging a lot of new JBoss OSGi dependencies (12 packages). As usual, you can watch the table for latest packaging info: https://fedoraproject.org/wiki/JBossAS7#Current_progress 2. New way of working with AS7 patches With 7.1.1-3 we reached more than 80 patches to the AS7 codebase to compile it and make it run on Fedora. The amount of patches was pretty close to what RHEL5 had :) It wasn't fun to manage it. So far I moved new subsystems to minimalistic profile and afterwards I build it. Over the time, when I added more and more subsystems - the patch set was growing. Since we have only a few modules not available in Fedora, starting from now - I'm building default profile and commenting out modules which are still not available. This simple step will save me a lot of work and make the development more stable. I think 7.1.1-4 is going to have about 25 patches. Once we'll have all AS7 deps available, the goal is to rebase one more time and leave only patches that are necessary and remove everything else. This will decrease the patch amount one more time. 3. New linked modules The new way of building mentioned in #3 showed me that I forgot to link some modules. This will be fixed and about 35 additional modules (/usr/share/jboss-as/modules/...) will be added. 4. ExampleDS available There was one issue hanging since some time in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=812522 In 7.1.1-4 we'll have the ExampleDS finally available! That's all! If you want to help me pushing 7.1.1-4 out, please take some packages for review: - https://bugzilla.redhat.com/show_bug.cgi?id=830763 (free to review) - https://bugzilla.redhat.com/show_bug.cgi?id=832446 - https://bugzilla.redhat.com/show_bug.cgi?id=832443 High priority is #830763, since it blocks everything else... If you have questions or need help, please join #fedora-java IRC channel on freenode. Thanks! P.S. If you have time, please consider also commenting on this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=827584 --Marek _______________________________________________ jboss-rpm mailing list jboss-rpm(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-rpm

2 1

Patching Maven pom.xml files
by Mikolaj Izdebski 28 Jun '12

28 Jun '12

Hello, recently a few new RPM macros that ease patching pom.xml files were introduced. Instead of creating and maintaining series of traditional patches you can now call %pom_* macros directly from the %prep section. These macros are described in /etc/rpm/macros.fjava, which is installed with javapackages-tools. There is also some guidance on usage of these macros included in the draft of Java packaging guidelines, available at: https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#Patc… Feel free to use these macros in your packages. For now this feature is available in Fedora Rawhide only, but there are plans on backporting it to Fedora 16 and 17. If you find any bugs or have any suggestions, please report them (here, on IRC or in Bugzilla -- javapackages-tools component). Mikolaj Izdebski

1 1

rpmbuild vs apache-ivy
by Fabiano Martins 28 Jun '12

28 Jun '12

Hi, I use Apache Solr4 on my organization, and plan pack it on a RPM and share with the Community. Sorry if my question is dumb, but I already read FAQs, docs, Google, and can't solve it alone... I did a specfile to build it, but the build.xml uses apache-ivy to resolve deps, and it automatically tries to download required libraries. I've put "BuildRequires" clauses on specfile, but I don't know how to made to Ivy use installed libraries instead of download them. An example: build needs apache-commons-codec-1.6. This package are installed, and contains the following files: /usr/share/doc/apache-commons-codec-1.6 /usr/share/doc/apache-commons-codec-1.6/LICENSE.txt /usr/share/doc/apache-commons-codec-1.6/NOTICE.txt /usr/share/doc/apache-commons-codec-1.6/RELEASE-NOTES.txt /usr/share/java/apache-commons-codec.jar /usr/share/java/commons-codec.jar /usr/share/maven-fragments/apache-commons-codec /usr/share/maven-poms/JPP-commons-codec.pom But when I try call "ant dist" from rpmbuild it fails with this message: (...) resolve: [ivy:retrieve] [ivy:retrieve] :: problems summary :: [ivy:retrieve] :::: WARNINGS [ivy:retrieve] module not found: commons-codec#commons-codec;1.6 [ivy:retrieve] ==== local: tried [ivy:retrieve] /home/fabiano/.ivy2/local/commons-codec/commons-codec/1.6/ivys/ivy.xml [ivy:retrieve] -- artifact commons-codec#commons-codec;1.6!commons-codec.jar: [ivy:retrieve] /home/fabiano/.ivy2/local/commons-codec/commons-codec/1.6/jars/commons-codec.jar [ivy:retrieve] ==== shared: tried [ivy:retrieve] /home/fabiano/.ivy2/shared/commons-codec/commons-codec/1.6/ivys/ivy.xml [ivy:retrieve] -- artifact commons-codec#commons-codec;1.6!commons-codec.jar: [ivy:retrieve] /home/fabiano/.ivy2/shared/commons-codec/commons-codec/1.6/jars/commons-codec.jar [ivy:retrieve] ==== public: tried [ivy:retrieve] http://repo1.maven.org/maven2/commons-codec/commons-codec/1.6/commons-codec… [ivy:retrieve] -- artifact commons-codec#commons-codec;1.6!commons-codec.jar: [ivy:retrieve] http://repo1.maven.org/maven2/commons-codec/commons-codec/1.6/commons-codec… [ivy:retrieve] ==== sonatype-releases: tried [ivy:retrieve] http://oss.sonatype.org/content/repositories/releases/commons-codec/commons… [ivy:retrieve] -- artifact commons-codec#commons-codec;1.6!commons-codec.jar: [ivy:retrieve] http://oss.sonatype.org/content/repositories/releases/commons-codec/commons… [ivy:retrieve] ==== working-chinese-mirror: tried [ivy:retrieve] http://mirror.netcologne.de/maven2/commons-codec/commons-codec/1.6/commons-… [ivy:retrieve] -- artifact commons-codec#commons-codec;1.6!commons-codec.jar: [ivy:retrieve] http://mirror.netcologne.de/maven2/commons-codec/commons-codec/1.6/commons-… [ivy:retrieve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: [ivy:retrieve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:retrieve] :: commons-codec#commons-codec;1.6: not found [ivy:retrieve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:retrieve] :::: ERRORS [ivy:retrieve] Server access Error: Connection timed out url=http://repo1.maven.org/maven2/commons-codec/commons-codec/1.6/commons-c… [ivy:retrieve] Server access Error: Connection timed out url=http://repo1.maven.org/maven2/commons-codec/commons-codec/1.6/commons-c… [ivy:retrieve] Server access Error: Connection timed out url=http://oss.sonatype.org/content/repositories/releases/commons-codec/com… [ivy:retrieve] Server access Error: Connection timed out url=http://oss.sonatype.org/content/repositories/releases/commons-codec/com… [ivy:retrieve] Server access Error: Connection timed out url=http://mirror.netcologne.de/maven2/commons-codec/commons-codec/1.6/commons-codec-1.6.pom [ivy:retrieve] Server access Error: Connection timed out url=http://mirror.netcologne.de/maven2/commons-codec/commons-codec/1.6/commons-codec-1.6.jar [ivy:retrieve] [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS BUILD FAILED /home/fabiano/rpmbuild/BUILD/branch_4x/solr/common-build.xml:320: The following error occurred while executing this line: /home/fabiano/rpmbuild/BUILD/branch_4x/lucene/module-build.xml:208: The following error occurred while executing this line: /home/fabiano/rpmbuild/BUILD/branch_4x/lucene/common-build.xml:287: impossible to resolve dependencies: resolve failed - see output for details -- Fabiano Martins Unidade de Aplicativos e Internet Divisão de Informática MPRS

2 2

Guacamole Java Web application
by Simone Caronni 20 Jun '12

20 Jun '12

Hello, sorry for double posting to devel and java-devel but the last seems not so crowded. On 24 May 2012 12:04, Simone Caronni <negativo17(a)gmail.com> wrote: > 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... > guacamole-common and guacamole-common-ext are now into rawhide and I've been struggling a couple of days for the next parts. I need some help with the guacamole-common-js [1][2]; the last step before packaging the web application itself [3]. The build itself is normally generated with the command "maven package"; so replacing it with "mvn-rpmbuild package" generates the following file. How's the supposed guideline for packaging it? Where should I put the zip file and how should the spec file be structured? All the other java classes for Guacamole are into jars in /usr/share/java/guacamole/. I can't find any useful information for it in the Java packaging pages [4]. I tried to look at at least 20 java packages in fedora and could not find one that was not packaging a jar file. $ unzip -l ./target/guacamole-common-js-0.6.0-guacamole-common-js.zip Archive: ./target/guacamole-common-js-0.6.0-guacamole-common-js.zip Length Date Time Name --------- ---------- ----- ---- 0 05-05-2012 04:32 guacamole-common-js/ 17214 05-05-2012 04:32 guacamole-common-js/mouse.js 31710 05-05-2012 04:32 guacamole-common-js/guacamole.js 17640 05-05-2012 04:32 guacamole-common-js/oskeyboard.js 12621 05-05-2012 04:32 guacamole-common-js/keyboard.js 24977 05-05-2012 04:32 guacamole-common-js/tunnel.js 37152 05-05-2012 04:32 guacamole-common-js/layer.js --------- ------- 141314 7 files [1] http://guac-dev.org/guacamole-common-js [2] http://slaanesh.fedorapeople.org/guacamole-common-js-0.6.0-1.fc17.src.rpm [3] http://guac-dev.org/guacamole [4] https://fedoraproject.org/wiki/Packaging:Java -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson).

2 4

AS 7 and Fedora marketing flyer preview
by Sarah White 18 Jun '12

18 Jun '12

Hi, I've pulled together the draft of the AS 7 and Fedora overview postcard text [1] (and mojavelinux is currently fact checking it). The plan is to have it printed up for the Summit and JAX San Francisco. Let me know if you have any questions or comments. The final version of the text will be completed on Monday 2012-06-18. [1] http://fedoraproject.org/wiki/JBossAS7_in_Fedora_marketing_collateral Cheers, Sarah (graphite6)

2 1

Maven packages in EPEL 6?
by Michel Alexandre Salim 16 Jun '12

16 Jun '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, First, a short self-introduction -- I'm a long-time Fedora contributor, who's currently working on a feature to [improve support for Clojure in Fedora](https://fedoraproject.org/wiki/Features/Clojure) Part of the rationale is that Kushal Das (cc:ed) and myself would like to eventually write some Fedora infrastructure in Clojure -- which would, of course, necessitate having the whole stack in RHEL/EPEL 6 as well. I noticed [a post by Lubomir](http://article.gmane.org/gmane.linux.redhat.fedora.java/3458/) back in 2010 asking for Maven packages to be made available in EPEL, but as we just discovered today, Maven is still not available. There seems to be no reply, at least on the mailing list, to that request.. Is there any technical difficulty involved in making these packages available on EPEL? If it's a lack of interest, Kushal and myself hereby volunteer to be the ones in charge of doing the EPEL maintenance work. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP0gRRAAoJEEr1VKujapN6EZ4IAIB2CNDozgmJdU23oreschws HcbyscUsLLJ/IZ3Bo4ezf2pjNCNnCrxQWil5RlOU5/W0OnduMzmiGnxmlby4OFUh szXpdxZ23UJChN8Twu3Bi/CA3qkqd/MZUIaGphGGI0BhT69pnh7iW6fEs3T93Cpv SLyD8PL7plE/xQiX20mmCzabHdyliOis8E64AAJ1zz5FIzyNTPYPboP6yM23qPXZ eFL3x5lLht1RA8M5wXtff6NLEZ9aEXpPJC5J0Qw5lWksd5VlYpDaHguz0SqIQnN1 p7vX7SR/kPZPpxBrQJg82bAZBpUEv/tMdbGfWaDly9koRsMeDcaRKNooaCqVVkA= =mwyf -----END PGP SIGNATURE-----

4 6

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel June 2012