gmane.linux.redhat.fedora.java

Re: Guacamole stack in Fedora

Simone Caronni — 2012-05-25T12:55:42

Hello,

On 25 May 2012 09:58, Stanislav Ochotnicky <sochotnicky< at >redhat.com> wrote:

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

Re: Guacamole stack in Fedora

Stanislav Ochotnicky — 2012-05-25T09:59:25

Quoting Simone Caronni (2012-05-25 10:57:57)

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.

Re: Guacamole stack in Fedora

Simone Caronni — 2012-05-25T08: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. < at > 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< at >r

Re: Guacamole stack in Fedora

Stanislav Ochotnicky — 2012-05-25T07:58:53

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)

Guacamole stack in Fedora

Simone Caronni — 2012-05-24T10: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

Re: Java Frameworks in Fedora?

Frank Murphy — 2012-05-21T16:32:01

Unfortunately it appears Orphaned.
http://tinyurl.com/7k2yuus

I will try find out why,
and if it can be given new life.
Otherwise will see if something new can be packaged.
(Famous last words)

Re: Java Frameworks in Fedora?

Pierre-Yves Chibon — 2012-05-21T16:09:00

Struts in the repo and is a web-app framework.

Pierre
--
java-devel mailing list
java-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Java Frameworks in Fedora?

Frank Murphy — 2012-05-21T16:03:17

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.

Flyer/Brochure for AS7 on Fedora

Sarah White — 2012-05-17T15:18:35

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< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Re: Handling of EE apis and other multipleimplementations

Stanislav Ochotnicky — 2012-05-17T14:46:21

Quoting Stanislav Ochotnicky (2012-05-11 11:53:40)

Mikolaj's questions on the discussion page made me think of a better
solution (already in  the draft):

 * %{_javadir}/javax.XXX will be a directory
 * this dir will contain all jars (symlinks) needed to use this API (api and impl)

This means things should work like this:

$ build-classpath javax.servlet.jsp
/usr/share/java/javax.servlet.jsp/glassfish-jsp-api.jar:/usr/share/java/javax.servlet.jsp/glassfish-jsp.jar

This is currently broken due to a bug in build-classpath script that
causes it to ignore symlinks to jar files. Possible issue here is that
other distributions taking our packages will be hitting weird bugs due
to this so we should get this into upstream. I don't see why they used
"-xtype f" in find instead of "-type f". Anyone knows?

Re: Handling of EE apis and othermultipleimplementations

Aleksandar Kurtakov — 2012-05-11T11:23:13


----- Original Message -----

This is supposed to be used only by package that need only the API as defined by some  JSR. All other use cases are hopeless and packages would have to choose what they work with for a number of reasons.

Alex

--
java-devel mailing list
java-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Re: Handling of EE apis and other multipleimplementations

Carlo de Wolf — 2012-05-11T09:57:57

Not all implementations follow the same functionality. In some cases 
defaults are provided within the implementation.

Carlo

--
java-devel mailing list
java-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Re: Handling of EE apis and other multipleimplementations

Stanislav Ochotnicky — 2012-05-11T09:53:40

Quoting Aleksandar Kurtakov (2012-05-10 16:55:14)

Agreed there. Minimal dependencies are a major selling point for me as
well. Unless of course there is some deficiency in the implementation.


Note to all, that we have a working draft[1] for new guidelines. There are
a few improvements (better explanation of %add_maven_depmap macro, few
more hints here and there), removal of old guideline cruft (mostly
maven2 related) and now I've added an initial EE api packaging
guideline.

See [2] for a diff against current guidelines. Feel free to tweak, add,
improve. We can review/fix/revert whatever changes come in later before
putting it to a vote during our overdue SIG meeting.

One thing I wonder about adding is that each javax.XX providing package
should also install additional file which would basically constitute
needed classpath to run the implementation (i.e. arguments for
build-classpath). For example "glassfish-jsp-api" would need
"glassfish-jsp" on the classpath so it would install let's say:
%{_javadir}/j

Re: Handling of EE apis and other multipleimplementations

Aleksandar Kurtakov — 2012-05-10T14:55:14


----- Original Message -----

I propose this being to be the implementation of the latest version with smallest number of dependencies - both runtime and build time. This should work pretty well as the packages that can work with whatever implementation are easy to port to new version too.


This proposal pretty much matches the osgi bundle names see http://download.eclipse.org/tools/orbit/downloads/drops/R20120119162704/
javax.activation
javax.annotation
javax.el 
javax.inject 
javax.jws  
javax.mail   
javax.management 
javax.management.remote 
javax.persistence 
javax.security.auth.message 
javax.servlet  
javax.servlet.jsp 
javax.servlet.jsp.jstl 
javax.transaction 
javax.ws.rs  
javax.wsdl  
javax.xml  
javax.xml.bind  
javax.xml.rpc 
javax.xml.soap
javax.xml.stream  
javax.xml.ws

So sticking close to each other would be even better.


No versions needed for the default. Every package that doesn't stick to the default should pick implementation on its own or ask for help to get ported.

I r

Handling of EE apis and other multiple implementations

Stanislav Ochotnicky — 2012-05-10T14:31:58

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

Re: -javadoc subpackages require jpackage-utils

Guido Grazioli — 2012-05-03T12:27:19

2012/5/3 Stanislav Ochotnicky

Yep that was what I pointed out myself in the bug above, but then
I was directed to this[1], and doubts started to arise. Even if,
actually, -javadocs packages seem to fit perfectly the "an exception"
warning box in that page.

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function



 --
Guido Grazioli <guido.grazioli< at >gmail.com>
Via Parri 11 48011 - Alfonsine (RA) (Italy)
3 Baltic Circuit - 3030 Point Cook - VIC (Australia)
Mobile: +39 347 1017202 (10-18 GMT+12)
Key FP = 7040 F398 0DED A737 7337  DAE1 12DC A698 5E81 2278
Linked in: http://www.linkedin.com/in/guidograzioli
--
java-devel mailing list
java-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Re: -javadoc subpackages require jpackage-utils

Stanislav Ochotnicky — 2012-05-03T09:42:34

Quoting Guido Grazioli (2012-05-02 09:22:36)

$ rpm -qvl jpackage-utils | grep javadoc
drwxr-xr-x    2 root    root 0 Mar 30 15:00 /usr/share/javadoc

I.e. jpackage-utils provides main javadoc directory

-javadoc subpackages require jpackage-utils

Guido Grazioli — 2012-05-02T07:22:36

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.

Re: multiple dependencies installed during yum update

Stanislav Ochotnicky — 2012-04-30T07:47:53

Quoting Guido Grazioli (2012-04-29 13:46:39)

jetty has been split into several sub-packages, jetty-osgi being the
largest with eclipse dependencies. I believe eclipse-platform Requires
is a bug and/or can be replaced by a different package. 

In any case: jetty is being worked on right now. This was a problem of
pulling in jetty-osgi in the first place. I'll fix it in the next
revision with few additional fixes

Re: multiple dependencies installed during yum update

Guido Grazioli — 2012-04-29T11:46:39

Il 29 aprile 2012 19:44, Johannes Lips ha scritto:


Here is output of yum history info:
http://guidograzioli.fedorapeople.org/yum-20120429.txt

It seems that update of jetty from 8.1.0-5 to 8.1.2-3 brought in
jetty-osgi, which in turn requires eclipse-platform, and most
dependencies were eclipse-platform dependencies.

Re: multiple dependencies installed during yum update

Johannes Lips — 2012-04-29T09:44:50

I think it would help if you could attach the output of the yum update. 
So that one could see which package pulled in those deps and if there is 
something wrong with it.

Johannes
On 04/29/2012 10:14 AM, Guido Grazioli wrote:

--
java-devel mailing list
java-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel