Eclipse plugins questions
by Gerard Ryan
-----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-----
11 years, 12 months
Guacamole stack in Fedora
by Simone Caronni
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-meeti...
>
>
> --
> 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).
12 years
Java Frameworks in Fedora?
by Frank Murphy
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"
12 years
Flyer/Brochure for AS7 on Fedora
by Sarah White
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
12 years
Handling of EE apis and other multiple implementations
by Stanislav Ochotnicky
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
12 years
