Consume Jersey and all dependencies using Maven repositories

[modular-mind]

Now that Eclipse target definitions can contain Maven artifacts, let's try to switch over from Orbit and other sources to directly get Jersey and all dependencies (Jackson, etc) directly from Maven repositories.

I'm guessing the best way to do this would be in isolation from the Jersey 3 upgrade, though we could do them both at the same time. In the Eclipse IDE, this requires m2e PDE 1.17.0 and Tycho requires 2.1.

The easiest way to add these artifacts is to modify the target definition source directly. Here's an example for Mockito:

    <location missingManifest="generate" type="Maven">
        <groupId>org.mockito</groupId>
        <artifactId>mockito-core</artifactId>
        <version>3.7.0</version>
        <type>jar</type>
    </location>

[scottslewis]

Hi Patrick.

I've added a target file that I've constructed with the Maven artifacts support. It's currently on branch: mvn_artifacts_in_target and the file is: org.eclipse.ecf.jaxrs.releng.target/ecf-jaxrs-2019-12_mvn.target

With this target set, I'm able to build JaxRSProviders projects in PDE. It does so with using p2 repos in the target for ECF and Eclipse, and maven central for all the Jersey, CXF, and their dependencies.

I have not yet tried to build with Tycho and this target platform...I'll probably try this weekend.

If this all works, I'll probably do a new release of the JaxRSProviders, and then begin looking into contributing the JaxRSProviders projects to the ECF Eclipse Foundation project. One thing I need to look into a little: What the EF rules are wrt redistributing (i.e. in p2 repo) artifacts from maven repos.

[modular-mind]

That's great! Let me know what you find out distributing Maven artifacts. I suppose this new target location type might open up a set of new issues around that. Was Orbit a way to "vet" third party libraries and make them acceptable for distribution?

[scottslewis]

Hi Patrick,

That's great! Let me know what you find out distributing Maven artifacts. I suppose this new target location type might open >up a set of new issues around that. Was Orbit a way to "vet" third party libraries and make them acceptable for distribution?

Yes, it played that role wrt 'vetting' source code (i.e. provenance, license compatibility, copyright mgmt, etc). The good thing is that Jersey is already an EF member, so it should be complying already with all the EF licensing/copyright/provenance stuff...and for it's dependencies (e.g. Jackson). I'm hopeful I will be able to just point to Jersey and say this code is dependent upon Jersey, and Jersey is an EF project so...but I'll have to figure that all out.

I've run into a bit of a snag wrt Tycho wrt the maven build support, however. It seems that Tycho 2.2 is not yet available on Maven Central (although it was recently released on Tycho site)...and afaict 2.2 is the one that has the maven artifact in target support. So for the moment I can build p2 repo with Eclipse + m2e PDE on the new branch, but I can't build it via maven/tycho (this is all with 2.30.1 of Jersey...not yet with 3.x of Jersey).

So while waiting for Tycho 2.2 being deployed to maven and looking into the EF licensing/deployment implications of using the maven artifacts in target, would you rather that I release a new version of JaxRSProviders (1.14.2)...with a few small metadata changes to support dependencies diffs...or wait until Tycho 2.2 is available?

[modular-mind]

I'm fine waiting until Tycho 2.2 is available and we've clarified the licensing issues. The functionality is where I need it to be right now.

[scottslewis]

Hi Patrick. FYI...the policy discussion around use of maven artifacts in Tycho/PDE builds (to produce maven repos) has begun here:

https://www.eclipse.org/lists/p2-dev/msg05910.html

FYI: I anticipate that this is going to be a while. The reason is that currently the EF has stronger signing requirements for Eclipse Foundation projects than Maven does for Maven Central. What that implies is that projects like ECF...that want to consume Jersey Maven artifacts won't necessarily be able to package and redistribute those artifacts as p2 repo as we must at ECF EF even if we can get them from maven via the new maven artifacts support in PDE and soon Tycho.

In the mean time, another possibility is that I build the JaxRSProvider and put the org.eclipse.ecf bundles on Maven Central...for your and others consumption via Maven Central (rather than as p2 repo as you have been doing). Even with the maven artifacts support (which is not fully there yet) this might not be ideal as there are some issues to work out with maven artifacts which will make them harder to use (e.g. not full support for deps, no notion of features/groups at this point).

Wanted to keep you updated. Things are moving toward full policy and technical support for maven artifacts in RCP libs and apps, but at EF the policy stuff might lag behind as there are a lot of stakeholders there.

[modular-mind]

Hi Scott, thanks for the update. I think for now it's best to keep the JaxRSProvider on GitHub and not mess around with Maven Central. I'm ok with waiting for the EF to make a decision, even if it's going to take a while....

BTW, I'm guessing the signature issue would be affected by whether OSGi metadata generation was required for a JAR in Maven Central.