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@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:
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@redhat.com Software Engineer - Base Operating Systems Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Hi,
I took the review. Comments in bugzilla, but don't worry...package looks good at first glance.
Quoting Simone Caronni (2012-05-24 12:04:08)
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@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:
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@redhat.com Software Engineer - Base Operating Systems Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- packaging mailing list packaging@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).
Many thanks.
Do you know what these warning messages mean when building the rpm?
[INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for net.sourceforge.guacamole:guacamole-common:jar:0.6.0 [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 18, column 21 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building guacamole-common 0.6.0 [INFO] ------------------------------------------------------------------------ [WARNING] The POM for javax.servlet:servlet-api:jar:2.5 is missing, no dependency information available [INFO]
Regards, --Simone
On 25 May 2012 09:58, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
Hi,
I took the review. Comments in bugzilla, but don't worry...package looks good at first glance.
Quoting Simone Caronni (2012-05-24 12:04:08)
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@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:
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@redhat.com Software Engineer - Base Operating Systems Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- packaging mailing list packaging@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).
-- Stanislav Ochotnicky sochotnicky@redhat.com Software Engineer - Base Operating Systems Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
Quoting Simone Caronni (2012-05-25 10:57:57)
Many thanks.
Do you know what these warning messages mean when building the rpm?
[INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for net.sourceforge.guacamole:guacamole-common:jar:0.6.0 [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 18, column 21 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building guacamole-common 0.6.0 [INFO] ------------------------------------------------------------------------ [WARNING] The POM for javax.servlet:servlet-api:jar:2.5 is missing, no dependency information available [INFO]
We are programmers. We ignore warnings :-)
Ok, gory details: For a long time we used to strip away parent pom information to simplify dependencies. In some cases there parent poms were used to define version of certain plugin for all children (so they wouldn't have to redefine). However by stripping away parent poms we lose that information. It's rarely a problem though and we are chipping away at it bit by bit.
Feel free to ignore them, just be aware of them.
Hello,
On 25 May 2012 09:58, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
I took the review. Comments in bugzilla, but don't worry...package looks good at first glance.
many thanks for the super quick review; now I'm moving forward with the other packages.
What should I do when I encounter a package with an empty assembly id?
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.3:attached (make-zip) on project guacamole-common-js: Assembly is incorrectly configured: null: Assembly is incorrectly configured: null: [ERROR] Assembly: null is not configured correctly: Assembly ID must be present and non-empty.
Thanks, --Simone
Hello,
On 25 May 2012 14:55, Simone Caronni negativo17@gmail.com wrote:
What should I do when I encounter a package with an empty assembly id?
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.3:attached (make-zip) on project guacamole-common-js: Assembly is incorrectly configured: null: Assembly is incorrectly configured: null: [ERROR] Assembly: null is not configured correctly: Assembly ID must be present and non-empty.
does anyone know how should I specify the assembly id tag?
Thanks, --Simone
Ok, figured out...
On 30 May 2012 13:09, Simone Caronni negativo17@gmail.com wrote:
Hello,
On 25 May 2012 14:55, Simone Caronni negativo17@gmail.com wrote:
What should I do when I encounter a package with an empty assembly id?
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.3:attached (make-zip) on project guacamole-common-js: Assembly is incorrectly configured: null: Assembly is incorrectly configured: null: [ERROR] Assembly: null is not configured correctly: Assembly ID must be present and non-empty.
does anyone know how should I specify the assembly id tag?
Thanks, --Simone
-- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson).
java-devel@lists.fedoraproject.org