proper URL for update site

[Mailaender]

https://raw.githubusercontent.com/ECF/JaxRSProviders/master/build/ as a p2 update site is not a good idea because that is not covered by a CDN and a volatile target. Please upload to https://download.eclipse.org/ so it can be picked up by mirrors as well.

[scottslewis]

Hi @Mailaender

This project/repo needs to have a new release produced with updated dependencies. I'm not going to upload this old version to download.eclipse.org until this happens (mostly because of jersey version dependencies along with jersey's dependencies).

I currently myself don't have the resources to work on such changes. If you or others do, or are willing/able to sponsor me in such work I would welcome and assist any contributions.

I'm closing this issue. If you are able to resource or assist with updating dependencies please open a new issue with 'Update Jersey Dependencies' in title.

Thanks.

[Mailaender]

I think it is fine to also upload this older version onto the download server. Never store release binaries in a git repository! If you tell me what exactly has to be updated regarding Jersey, I can take a look and see if I can contribute a patch.

[scottslewis]

Hi @Mailaender . I appreciate the advice but I'm not going that way with the existing binaries.

The features in features/org.eclipse.ecf.provider.jersey.* have the required jersey bundle references. And the target platform named ecf-jaxrs-2020-12.target in releng directory is the current one.

In the target are these two directory locations:

as you will see in lib it's currently using jersey 2.30.1, which is a very old version of jersey.

Just for the record: I would rather be using Maven to pull in Jersey and its dependencies, but at the time the target was created (2020) Eclipse's target platform/tycho didn't have full maven support. In any event, using Directory locations should be removed/replaced. Also github actions/builds should be done. Two other things that you/others are welcome to do.

The difficulty is that Jersey moved to using jakarta servlet and jakarta jaxrs API in jersey 3.0, and I'm not sure of the status of OSGi servlet API wrt the jarkarta.servlet API and the jakarta.jaxrs API...which requires code changes in this provider code because of the package renaming from javax.jaxrs -> jakarta.jaxrs. So this is the hard part: Can jarkarta APIs (both servlet and jaxrs) be used on a more recent version of OSGI...specifiically some version of the OSGi Http Service...which is used in the ECF provider code, At the time I looked at this years ago, there was no OSGI HTTP Service that could use the jakarta.servlet API. There might be now some implementation (jetty, etc) that provides a version of the OSGI HTTP Service that uses/supports jakarta.servlet and jakarta.jaxrs (as Jersey 3 requires).

The api and impl layering looks like this:

ECF JaxRS Jersey Provider
Jersey impl of JaxRS (2.x - javax.jaxrs, 3.x - jakarta.jaxrs), OSGI HTTP Service (old - javax.servlet, new - ??)
HTTP Server Impl (old-javax.servlet, 'new' - jakarta.servlet)
OSGi
Java

I would encourage opening another issue, and we can continue as needed.

[Mailaender]

I see. Created #48 and #49. I am interested in trying this. Still I think those are actually unrelated to this problem of storing binaries in git and using source code hotlinks to act as a p2 repository.