Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] distribution providers
On 9/21/2015 2:40 PM, Wim Jongman wrote:

If they are bundles that should not be hard but we still need IP clearance.


They are bundles.  

But why would we still need IP clearance if we

a) build and distribute them ourselves?  (i.e. not part of ECF SDK but rather e.g. from github)?
b) don't ask the EF to sign them

Scott

I will try to build it with a maven repo.

On Sep 21, 2015, at 23:13, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
On 9/21/2015 1:06 PM, Wim Jongman wrote:
[ERROR]   Software being installed: org.eclipse.ecf.provider.jersey.server 1.0.0.qualifier
[ERROR]   Missing requirement: org.eclipse.ecf.provider.jersey.server 1.0.0.qualifier requires 'package org.glassfish.jersey.server 2.14.0' but it could not be found

We can also include it as a fat jar. At least we need to get IP clearance for the whole suite. Did you get that?

Yes.  I worked around it by downloading the jersey.server 2.14.0 via one of the public maven repos.   Unfortunately, as a result of using jersey-server-2.14.jar, a number of the jersey dependencies had to also be updated (see list below).

I've been corresponding with Rolund Grunberg about updating the Orbit version of jersey client and dependencies...and also adding jersey.server.  The current Jersey version is 2.21 [1], and other Orbit consumers are asking for a more recent version, and Rolund agrees it's about time.  But he's apparently somewhat bandwidth limited for Jersey-in-Orbit.

But unfortunately that's likely going to take a while (update jersey client and necessary deps in Orbit, add jersey.server and deps), EF approval process, etc.   I've offered to help with it, but unfortunately I can only do so much there.  Maybe you should write to Red Hat...I've done that a fair amount recently (I couldn't get a response from Mat Booth).

I've sort of wondered:  how much work would it be to build using Tycho and pull Jersey + deps from public maven repo?

Scott

jersey server jar and dependencies

hk2-api-2.4.0-b09.jar      jersey-container-servlet-core-2.14.jar
hk2-locator-2.4.0-b09.jar  jersey-server-2.14.jar
hk2-utils-2.4.0-b09.jar    validation-api-1.1.0.Final.jar
javassist-3.18.2-GA.jar


Cheers,

Wim



On Thu, Sep 10, 2015 at 6:24 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
On 9/10/2015 5:28 AM, Wim Jongman wrote:
I've made a beginning Tycho build for this project [1].

cd JaxRSProviders
mvn clean   // requires mvn 3.3+

* If you want to try the build, add a file to your local ~/.m2 directory as described here [2]
* Build currently breaks because I don't have a 3.11.0 repo yet.

Hi Wim,

Some things to consider (and possibly discuss in call/meeting if you wish):

1) The Glassfish Jersey version currently in Orbit (2.14) [1], works ok for the client, but the org.glassfish.jersey.server bundle (required for server provider) is not currently in Orbit.  Further, I had to update several of Jersey's Orbit dependencies (beyond 2.14) to use the jersey server bundle.   I've been corresponding directly with Roland Grunberg at Red Hat (he is the maintainer of the Jersey bundles in Orbit [1]) about updating the Orbit version (2.14 is a little stale now) and it's dependencies.  According to Roland this is a significant job (Jersey has quite a few deps) and so if we want this to happen we should try to coordinate with Roland and/or Mat on getting it accomplished.  Another option is that we simply use a more recent version of Jersey from Maven Central (or wherever).   I'm personally indifferent about this, but it obviously has build, IP, EF, distribution implications.

2) There's no version of CXF in Orbit, so we either have to take that on (which I'm not personally willing to do, but am OK if others wish to do it), or build/distribute against non-Orbit versions of CXF bundles and it's extent of dependencies (which is fairly complicated, and I haven't tried to figure out or even test yet).

Let me know if you want to discuss in call/meeting.

Scott

[1] http://download.eclipse.org/tools/orbit/downloads/drops/R20150821153341/




On Thu, Sep 10, 2015 at 12:32 PM, Wim Jongman <wim.jongman@xxxxxxxxx> wrote:
Hi Scott,

I am happy to try this. Ping me frequent with the status. Do you have tests in place?
 I am going for Tycho for this one. I am waiting for an opportunity to try their new "pomless" feature.

Cheers,

Wim


On Wed, Sep 9, 2015 at 9:26 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Folks,

Over the past few weeks, I've used the new ECF 3.11.0 provider API to create several new providers.  First, I've created several providers based upon Jax Rest Services (Jax RS) specification...specifically the implementations from Jersey, CXF, and started one based upon RestEasy.   I designed these bundles to reuse common classes (dependent upon Jax-RS...e.g. javax.ws.rs packages) so that it's now much easier to introduce additional Jax-RS implementations (e.g. Restlet).

These JaxRS-based providers are in this repo [1], along with some examples.

I've also created some tutorials [2] describing how REST-standards-based remote services can easily be created...and be completely independent of any REST implementation, or even any remote services implementation.

I would like to request assistance from other committers and/or ECF contributors in setting up the build/distribution meta-data for these projects, so that we can build them and make them available as bundles.   The various Jax-RS implementations are relatively large (e.g. Jersey, CXF, etc) and have quite a few dependencies of their own.  The good news is that at least Jersey bundles are available from Orbit, the bad news is that the version in Orbit needs to be upgraded and the original Orbit contributor needs some assistance with an upgrade of the Jersey version in Orbit.

CXF is distributed as bundles, but it's not in Orbit.   It is in maven repos, as are most or maybe all of it's dependencies. It has a significant number of dependencies and so getting all the versions correct, etc. could be an effort for someone not familiar with CXF internals.

As you can tell, there's a fair amount to do to build and deploy these providers, provide a way for consumers to install all dependencies (via both p2 repo and Karaf features).  I request some help with that, as it would be very nice for people to be able to easily switch among several distribution providers for their remote services.

Thanksinadvance for your contributions.

Scott

[1] https://github.com/ECF/JaxRSProviders
[2] https://wiki.eclipse.org/Tutorial:_Using_REST_and_OSGi_Standards_for_Micro_Services
https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev 




_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev 



_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev

 

ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top