Chosing implementations for EE APIs and finalizing guidelines
by Stanislav Ochotnicky
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...
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
11 years, 11 months
JBoss AS 7 packaging effort update
by Marek Goldmann
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
11 years, 11 months
Patching Maven pom.xml files
by Mikolaj Izdebski
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#Pa...
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
11 years, 11 months
rpmbuild vs apache-ivy
by Fabiano Martins
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-cod...
[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-cod...
[ivy:retrieve] ==== sonatype-releases: tried
[ivy:retrieve]
http://oss.sonatype.org/content/repositories/releases/commons-codec/commo...
[ivy:retrieve] -- artifact
commons-codec#commons-codec;1.6!commons-codec.jar:
[ivy:retrieve]
http://oss.sonatype.org/content/repositories/releases/commons-codec/commo...
[ivy:retrieve] ==== working-chinese-mirror: tried
[ivy:retrieve]
http://mirror.netcologne.de/maven2/commons-codec/commons-codec/1.6/common...
[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/common...
[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...
[ivy:retrieve] Server access Error: Connection timed out
url=http://repo1.maven.org/maven2/commons-codec/commons-codec/1.6/commons...
[ivy:retrieve] Server access Error: Connection timed out
url=http://oss.sonatype.org/content/repositories/releases/commons-codec/c...
[ivy:retrieve] Server access Error: Connection timed out
url=http://oss.sonatype.org/content/repositories/releases/commons-codec/c...
[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
11 years, 11 months
Guacamole Java Web application
by Simone Caronni
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).
12 years
Maven packages in EPEL 6?
by Michel Alexandre Salim
-----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-----
12 years
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-----
12 years
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
