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  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
guacamole - The main web application, written in Java.
guacamole-common - The Java API used by the web application.
guacamole-ext - Common interfaces for extending the main web application.
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  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 
My first attempt is to package "guacamole-common" ; 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 ?
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-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 and  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
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Red Hat Inc. http://cz.redhat.com
packaging mailing list
You cannot discover new oceans unless you have the courage to lose
sight of the shore (R. W. Emerson).