OK - I think the right solution here is going to be RESTeasy. Why? Because I was able to find the guy who is responsible for getting the JBOSS packages into fedora. We were able to determine the five or six packages that need to be added to fedora to get us the functionality we need. While that number is likely to get bigger, we can get this prioritized if we help him. So thats what we should do. Here is mgoldmann's link to a template he is using for packages, and couple of other useful links: https://gist.github.com/1383245 http://resteasy.svn.sourceforge.net/viewvc/resteasy/tags/RESTEASY_JAXRS_2_2_3_GA/resteasy-jaxrs/pom.xml?revision=1569&view=markup http://fedoraproject.org/wiki/JBossAS7#Wishlist Ade On Mon, 2011-11-21 at 09:29 -0500, Ade Lee wrote:

Adam,

I'm not sure what you built - but your build seems to lack a lot of key dependencies. I pulled down the jersey source from svn and tried to build it using eclipse (and immediately ran into 50K+ build errors).

I then built it in maven and noticed something like 450 jars being pulled in. Now granted, lots of these are duplicate versions - and some of these are in fedora - but a lot of them are not.

I tried to figure out which ones are provided by fedora but its slow going. Attached is the list of jars pulled in (pulled_jars) and a slightly more whittled down list after removing multiple versions or seeing the jar in fedora. The whittled down list can probably be whittled down further.

Its still over 250 jars long though. Even if we managed to whittle down much further its likely we will end up with over 100 jars that we would need to shepherd through fedora and rhel acceptance. Including a few that would be unacceptable in fedora/rhel.

As you say, resteasy is probably a little worse - although in this case, we *might* be able to find folks to maintain some parts of this.

So this begs the question - are either of these frameworks feasible for us to use at the current time?

Ade

On Fri, 2011-11-18 at 12:54 -0500, Adam Young wrote:

...

I first ran the maven Archtype for a Jersey web app and then compiled it. Both before starting and In between the two steps I wiped out my local Maven repository to be able to distinguish waht was necessary.

Here are the list of jars pulled down in the second stage.

javax/ws/rs/jsr311-api/0.8/jsr311-api-0.8.jar junit/junit/3.8.1/junit-3.8.1.jar commons-cli/commons-cli/1.0/commons-cli-1.0.jar org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar org/codehaus/mojo/tomcat-maven-plugin/1.1/tomcat-maven-plugin-1.1.jar org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar asm/asm/3.1/asm-3.1.jar com/sun/jersey/jersey/0.8-ea-SNAPSHOT/jersey-0.8-ea-SNAPSHOT.jar

I'm guessing these fall into two groups: those needed for building any web app and those specific to Jersey. Maven is fairly well covered by Fedora, so I don't think w'll have too much trouble there. JUnit is in Fedora. commons-cli is in fedora

jsr311 is probably just a small set of source file, but it is not in Fedora.

Specific to Jersey are these: edited out of the Jersey POM

javax.ws.rs.jsr311-api version 0.8 javax.annotation.jsr250-api version 1.0 javax.persistence.persistence-api version 1.0.2 javax.servlet.servlet-api version 2.5 asm.asm version 3.1

NOte that does not indicated what is needed to build Jersey, merely what it requires to build another project.

Pulling the Jersey source into Eclipse without and jars to fill in dependencies is more interesting.

To build, it refers to a bunch of the Sun classes in the JREs rt.jar, which have access prohibited. we can work around this with a symlink.

Other jars I started pulling in

<classpathentry kind="lib" path="/usr/share/java/javamail/mail.jar"/> <classpathentry kind="lib" path="/usr/share/java/geronimo-annotation.jar"/> <classpathentry kind="lib" path="/usr/share/java/objectweb-asm/asm.jar"/> <classpathentry kind="lib" path="/usr/share/java/felix/org.osgi.core.jar"/> <classpathentry kind="lib" path="rt.jar"/> <classpathentry kind="lib" path="/usr/share/java/ant.jar"/> <classpathentry kind="lib" path="/usr/share/java/jsp.jar"/> <classpathentry kind="lib" path="/usr/share/java/tomcat6/annotations-api.jar"/> <classpathentry kind="lib" path="/usr/share/java/geronimo-ejb.jar"/> <classpathentry kind="lib" path="/usr/share/java/atinject.jar"/> <classpathentry kind="lib" path="/usr/share/java/geronimo-jpa.jar"/> <classpathentry kind="lib" path="/usr/share/java/tomcat-servlet-3.0-api.jar"/> <classpathentry kind="lib" path="/usr/share/java/geronimo-interceptor.jar"/>

The only one I haven't found so far is <classpathentry kind="lib" path="/home/ayoung/.m2/repository/javax/enterprise/cdi-api/1.1.EDR1.1/cdi-api-1.1.EDR1.1.jar"/>

Which appears to be Weld, or the reference implementation of JSR-299. This looks interesting in its own right.

_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

On 11/21/2011 09:29 AM, Ade Lee wrote:

Adam,

I'm not sure what you built - but your build seems to lack a lot of key dependencies. I pulled down the jersey source from svn and tried to build it using eclipse (and immediately ran into 50K+ build errors).

I then built it in maven and noticed something like 450 jars being pulled in. Now granted, lots of these are duplicate versions - and some of these are in fedora - but a lot of them are not.

I tried to figure out which ones are provided by fedora but its slow going. Attached is the list of jars pulled in (pulled_jars) and a slightly more whittled down list after removing multiple versions or seeing the jar in fedora. The whittled down list can probably be whittled down further.

Its still over 250 jars long though. Even if we managed to whittle down much further its likely we will end up with over 100 jars that we would need to shepherd through fedora and rhel acceptance. Including a few that would be unacceptable in fedora/rhel.

As you say, resteasy is probably a little worse - although in this case, we *might* be able to find folks to maintain some parts of this.

So this begs the question - are either of these frameworks feasible for us to use at the current time? I'll have to tkae a closer look, but I do know that I commented out the grizzley web server. that pulls in a few, and it really makes no sense.

There are a bunch that get pulled in just for Maven, but that are not required for building. Most of these should be things that are already accounted for. I think Jersey is do-able.

Ade

On Fri, 2011-11-18 at 12:54 -0500, Adam Young wrote:

...

I first ran the maven Archtype for a Jersey web app and then compiled it. Both before starting and In between the two steps I wiped out my local Maven repository to be able to distinguish waht was necessary.

Here are the list of jars pulled down in the second stage.

javax/ws/rs/jsr311-api/0.8/jsr311-api-0.8.jar junit/junit/3.8.1/junit-3.8.1.jar commons-cli/commons-cli/1.0/commons-cli-1.0.jar org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar org/codehaus/mojo/tomcat-maven-plugin/1.1/tomcat-maven-plugin-1.1.jar org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar asm/asm/3.1/asm-3.1.jar com/sun/jersey/jersey/0.8-ea-SNAPSHOT/jersey-0.8-ea-SNAPSHOT.jar

I'm guessing these fall into two groups: those needed for building any web app and those specific to Jersey. Maven is fairly well covered by Fedora, so I don't think w'll have too much trouble there. JUnit is in Fedora. commons-cli is in fedora

jsr311 is probably just a small set of source file, but it is not in Fedora.

Specific to Jersey are these: edited out of the Jersey POM

javax.ws.rs.jsr311-api version 0.8 javax.annotation.jsr250-api version 1.0 javax.persistence.persistence-api version 1.0.2 javax.servlet.servlet-api version 2.5 asm.asm version 3.1

NOte that does not indicated what is needed to build Jersey, merely what it requires to build another project.

Pulling the Jersey source into Eclipse without and jars to fill in dependencies is more interesting.

To build, it refers to a bunch of the Sun classes in the JREs rt.jar, which have access prohibited. we can work around this with a symlink.

Other jars I started pulling in

<classpathentry kind="lib" path="/usr/share/java/javamail/mail.jar"/> <classpathentry kind="lib" path="/usr/share/java/geronimo-annotation.jar"/> <classpathentry kind="lib" path="/usr/share/java/objectweb-asm/asm.jar"/> <classpathentry kind="lib" path="/usr/share/java/felix/org.osgi.core.jar"/> <classpathentry kind="lib" path="rt.jar"/> <classpathentry kind="lib" path="/usr/share/java/ant.jar"/> <classpathentry kind="lib" path="/usr/share/java/jsp.jar"/> <classpathentry kind="lib" path="/usr/share/java/tomcat6/annotations-api.jar"/> <classpathentry kind="lib" path="/usr/share/java/geronimo-ejb.jar"/> <classpathentry kind="lib" path="/usr/share/java/atinject.jar"/> <classpathentry kind="lib" path="/usr/share/java/geronimo-jpa.jar"/> <classpathentry kind="lib" path="/usr/share/java/tomcat-servlet-3.0-api.jar"/> <classpathentry kind="lib" path="/usr/share/java/geronimo-interceptor.jar"/>

The only one I haven't found so far is <classpathentry kind="lib" path="/home/ayoung/.m2/repository/javax/enterprise/cdi-api/1.1.EDR1.1/cdi-api-1.1.EDR1.1.jar"/>

Which appears to be Weld, or the reference implementation of JSR-299. This looks interesting in its own right.