http://blog.gmane.org/gmane.linux.redhat.fedora.java hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.redhat.fedora.java/4074 <pre>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 &lt;sochotnicky&lt; at &gt;redhat.com&gt; wrote: </pre> Simone Caronni 2012-05-24T10:04:08 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4071 <pre>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. </pre> Frank Murphy 2012-05-21T16:03:17 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4070 <pre>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 -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Sarah White 2012-05-17T15:18:35 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4064 <pre>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 </pre> Stanislav Ochotnicky 2012-05-10T14:31:58 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4061 <pre>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. </pre> Guido Grazioli 2012-05-02T07:22:36 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4057 <pre>Hello, today after running, as usual, yum update --skip-broken on rawhide, i got several java packages installed as dependencies, I mean about 40 megs of rpms, some ant-, a lot of jetty-, mongo-, lucene-contrib, some felix-, down to some eclipse-). I can post the full list if needed. The only java packages I had installed in rawhide before the update were: jetty, jboss-, maven- and their dependencies (and openjdk). Is all that an intended behaviour? Guido </pre> Guido Grazioli 2012-04-29T09:14:27 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4048 <pre>Tomorrow we'll have a Fedora Test Day for JBoss AS, more information on the wiki page: https://fedoraproject.org/wiki/Test_Day:2012-04-17_JBoss_Application_Server See you! --Marek -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Marek Goldmann 2012-04-16T20:38:34 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4047 <pre>We could shave off a few cpu and i/o cycles by doing mvn-rpmbuild verify instead of install [1] on packages that do not need the artifact to be available in the local cache further down the %build or %install section. Carlo [1] https://fedoraproject.org/wiki/Packaging:Java#maven3 -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Carlo de Wolf 2012-04-16T13:24:30 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4046 <pre>hi all! i'm trying to update and build maven-ant-tasks for gradle, maven-ant-tasks uses maven 2, and i am having problems. i am receiving a mvn-jpp not found error in my build log. Here are the links to spec, srpm, and koji. Any suggestions? Thanks! http://cerberus.fedorapeople.org/maven-ant-tasks/2.1.3/1/maven-ant-tasks.spec http://cerberus.fedorapeople.org/maven-ant-tasks/2.1.3/1/maven-ant-tasks-2.1.3-1.fc16.src.rpm http://koji.fedoraproject.org/koji/taskinfo?taskID=3991366 -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Anthony Sasadeusz 2012-04-14T20:25:52 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4043 <pre>I'm seeing: + /usr/lib64/eclipse/buildscripts/pdebuild -d 'cdt cdt-parsers jgit rse' -f org.eclipse.ptp.utils -a '-DjavacSource=1.5 -DjavacTarget=1.5 -Dnoclean=true' pdebuild was renamed into eclipse-pdebuild and moved into _bindir Looks like https://fedoraproject.org/wiki/Packaging/EclipsePlugins#pdebuild needs to be updated. But we need to make things conditional for F17+ and before. Perhaps eclipse-pde should define a macro for it, but it would need to get pushed all the way down to F15 to be useful. Otherwise every package will probably need to put in a conditional if you want to have a common spec for all releases. Thoughts? </pre> Orion Poplawski 2012-04-13T15:18:04 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4040 <pre>Quick heads-up: JBoss AS 7 package (jboss-as) was approved, it'll be available in Rawhide and Fedora 17 soon! --Marek -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Marek Goldmann 2012-04-05T11:42:29 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4039 <pre>Hello, all - I just thought I would introduce myself. My name is Zack, and I am hoping to participate to GSOC this year by helping contribute to the Fedora Project. My proposal is based creating spins of Fedora based on using JBoss tools and community packages for application development, which I've submitted it over at Google Melange&lt;http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dzack/1&gt; . I would greatly appreciate any feedback or comments on it, as I would really like to produce something the community will enjoy using. I am also still currently looking for a mentor, and would welcome any guidance in that respect. Thank you for your time, and I look forward to hopefully working with you all! -Zack Garza User Page: https://fedoraproject.org/wiki/User:Dzack -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Zack Garza 2012-04-04T16:11:36 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4038 <pre>Hello everybody. My name is Anthony Sasadeusz and I would really appreciate some feedback and comments on my proposal. The link to it is provided. Thanks in advance. https://fedoraproject.org/wiki/GSOC_2012/Student_Application_Cerberus/Fedora_JBoss_spin - Anthony -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Anthony Sasadeusz 2012-04-03T16:42:23 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4035 <pre>I have created a draft proposal[1] for Java API/ABI Checker{idea proposed by  Stanislav Ochotnicky[4]}. I have limited my scope to a few features rather than addressing all/many, to create a good deliverable. This mostly proposes building features over python-javaclass[2] and pkgdiff along with the Web-Repo. I welcome any feedback and changes to the proposal. An overview of the proposal rests at [3] [1] https://fedoraproject.org/wiki/GSOC_2012/Student_Application_Vipulnsward/Java_API-ABI_Checker [2] https://github.com/obriencj/python-javaclass [3] https://fedoraproject.org/wiki/GSOC_2012/Student_Application_Vipulnsward/Java_API-ABI_Checker#Proposal_Description [4] https://fedoraproject.org/wiki/User:Sochotni Vipul A.M. +91-8149-204995 -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Vipul Amler 2012-04-03T07:54:14 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4031 <pre>Are there any plans to add java-1.7.0-openjdk to EPEL? Is there a particular reason (compatibility, RH is planning to ship it in a RHEL update, something like that) why it could or should not be done, other than no one doing it yet? Best, - Michael -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Michael Ekstrand 2012-03-25T13:38:54 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4026 <pre>Hello, I'm trying to package all of the separate components of shrinkwrap. So to start off with I try to build the entire project against rawhide, investigate the dependencies and then build the seperate packages. The problem I am having is maven-enforcer-plugin fails with a message JAVA5_HOME needs to be set. Here is part of the build log. [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building ShrinkWrap Aggregator and Build Parent 1.0.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java-version) &lt; at &gt; shrinkwrap-parent --- [WARNING] Rule 3: org.apache.maven.plugins.enforcer.RequireProperty failed with message: "JAVA5_HOME needs to be set to run some tests in the JRE5 runtime" [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Skipping ShrinkWrap Aggregator and Build Parent [INFO] This project has been banned from the build due to previous failures. [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] ShrinkWrap Aggregator and Build Parent ............ FAILURE [0.430s] [INFO] Shrinkwrap Build Resources ........................ SKIPPED [INFO] ShrinkWrap API .................................... SKIPPED [INFO] ShrinkWrap Bill of Materials ...................... SKIPPED [INFO] ShrinkWrap SPI .................................... SKIPPED [INFO] ShrinkWrap Implementation Base .................... SKIPPED [INFO] ShrinkWrap Dependency Chain ....................... SKIPPED [INFO] ShrinkWrap Distribution ........................... SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.134s [INFO] Finished at: Mon Mar 19 03:37:50 UTC 2012 [INFO] Final Memory: 15M/210M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce (enforce-java-version) on project shrinkwrap-parent: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed. -&gt; [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException error: Bad exit status from /var/tmp/rpm-tmp.VFfrT2 (%build) Bad exit status from /var/tmp/rpm-tmp.VFfrT2 (%build) RPM build errors: Child returncode was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target noarch --nodeps builddir/build/SPECS/shrinkwrap.spec'] Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 352, in do raise mockbuild.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target noarch --nodeps builddir/build/SPECS/shrinkwrap.spec'] LEAVE do --&gt; EXCEPTION RAISED -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Anthony Sasadeusz 2012-03-19T04:21:21 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4024 <pre>Hi, OpenJDK6 will no longer be getting security updates after November 2012. Since the lifespan of Fedora 17 is well beyond this, we have been working toward being able to remove java-1.6.0-openjdk from Fedora 16 and proposed so in the F17 Java 7 feature: http://fedoraproject.org/wiki/Features/Java7 We have re-built most packages that failed to build with Java 7: https://fedoraproject.org/wiki/Java7_Package_Rebuild_Status Most of what remains above is an FTFBS unrelated to Java 7. To that end, I will be orphaning java-1.6.0-openjdk from F17 and rawhide tomorrow -- this is just a heads up email. Cheers, Deepak -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Deepak Bhole 2012-03-14T15:41:30 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4022 <pre>Hello, I recently received the following bug against freemind. https://bugzilla.redhat.com/show_bug.cgi?id=800769 One working solution is to just add cd /usr/share/freemind into the startup script but I just wanted to know if that is possible and also why the current definition of the working directory in the startup script is not working. The current startup script looks like this: http://pkgs.fedoraproject.org/gitweb/?p=freemind.git;a=blob;f=freemind.sh;h=76322cccaa435d2c000d406b298c7d188f00e822;hb=HEAD Hope we could find an easy solution since it will really fix the Export problems we have with freemind. Thanks for any suggestions, Johannes -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Johannes Lips 2012-03-08T12:01:37 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4020 <pre> Hi, I believe it might be nice to get everyone up to speed on what is happening in Java world in Fedora and what is planned in near future. 1. Packaging guidelines updates - I'd like to add guidelines for packaging compat libraries. Maven already has support for this (see [1]) so I'd like to describe how to package compat things properly. Together with unversioned jars we already have, this is gonna make things easier. I'll add big red "DON'T DO THIS IF YOU DON'T HAVE TO" of course... - Remove mention of maven2 in guidelines since all supported versions have maven-3.x. Some other small cleanups as well perhaps - Add optional use of %generate_javadoc macro that automates generating of javadoc subpackages (already available for a while, not used though :-) ) - Update JNI part of the guidelines to reflect current practice. The guidelines are actually out of date for JNI. - If you have things you'd like to include, please do changes directly to [2] and we can discuss them later. We can always revert them if we decide not to do whatever you come up with. Just propose something sane :-) 2. Improvements to Maven packaging and creating of Maven repository - Carlo de Wolf is working on new maven macros/extension[3] that would enable us to provide a proper Maven repository to developers so that they can test against our Fedora versions more easily - There are still a few questions that need to be answered, but I believe this will be the future for us barring any catastrophic failures :-) 3. Various packaging efforts - JBoss AS 7 A F17 feature, a big chunk of JBoss AS 7 has already been packaged, but more packages are still on the way. I am sure Marek Goldman who is the main person driving this effort will appreciate any package reviewers wanting to drop by. See [4] for current status - Resteasy, Picketbox, Hibernate and few other things Work being done by various people on #fedora-java. Currently some work depends on JBoss being packaged so we'll see how it goes. It would be nice to have some real-time status of these things I guess so for the future I created [5]. If you have something to add, please do so! I CCed fedora-java, please post replies to devel&lt; at &gt; though :-) [1] https://bugzilla.redhat.com/show_bug.cgi?id=757732 [2] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate [3] https://github.com/wolfc/fedora-maven [4] https://fedoraproject.org/wiki/JBossAS7#Current_progress [5] https://fedoraproject.org/wiki/SIGs/Java#Ongoing_projects </pre> Stanislav Ochotnicky 2012-03-07T15:53:55 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4019 <pre> I have just pushed an updated jetty 8.1.x into rawhide and F17[1]. Most of the things should work and it would be nice if it got some wider testing since we updated from 6.x to 8.1.x between F16 and F17. If you have a web application or anything that you use with jetty, please try it out and report any bugs you encounter. The spec has been done from the group up more-less, so even trivial bugs can start appearing (i.e such as user creation that was broken in first releases). [1] https://admin.fedoraproject.org/updates/jetty-8.1.0-3.fc17 </pre> Stanislav Ochotnicky 2012-02-23T16:54:27 http://comments.gmane.org/gmane.linux.redhat.fedora.java/4018 <pre>Hi, The Java packaging guidelines [1] currently require a versioned dependency on java: At a minimum, Java packages MUST: BuildRequires: java-devel [&gt;= specific_version] BuildRequires: jpackage-utils Requires: java &gt;= specific_version Requires: jpackage-utils This does not seem to reflect reality, as many recently-approved packages do not require a minimum version. Can the mandatory java version be made optional like the java-devel one? [1] https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires -- java-devel mailing list java-devel&lt; at &gt;lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel</pre> Garrett Holmstrom 2012-02-22T18:21:35 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.redhat.fedora.java