Remove SLF4J Plugin from o.e.passage.lic.oshi feature

[HannesWell]

If a Feature includes a Plugin, it usually includes it with a specific name and the version that was in the TP when the feature was build. This prevents consumers from using a slf4j bundle with different symbolic-name or different version in their TP or product.

This is part of eclipse-platform/eclipse.platform.releng.aggregator#588

[codecov]

Codecov Report

Merging #1127 (7d208fa) into master (70266f3) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1127   +/-   ##
=========================================
  Coverage     33.58%   33.58%           
  Complexity      359      359           
=========================================
  Files          1161     1161           
  Lines         25738    25738           
  Branches       1592     1592           
=========================================
  Hits           8644     8644           
  Misses        16574    16574           
  Partials        520      520           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[ruspl-afed]

This bundle was added to guarantee that Passage update site is self-sufficient. Who will supply this bundle if we remove it from this feature @HannesWell ?

[HannesWell]

This bundle was added to guarantee that Passage update site is self-sufficient. Who will supply this bundle if we remove it from this feature @HannesWell ?

In order to ensure that a p2-repo is self-contained I recommend to use includeAllDependencies of the tycho-p2-repository.
To SimRel SLF4J is for example supplied by Eclipse-Platform or Eclipse-M2E, but we are about to change to the variant from Maven-Central.

The important part about the removal from the feature is, that Plugins included in feature are forced with that exact bundle-name and version into Products that install that feature. If it is not included Product-builders can overwrite the 'default' for example from the SimRel repo that will be fetched by P2 with a newer version. Nevertheless P2 will always ensure that there is one version available to satisfy all Plugin requirements.

[ruspl-afed]

I recommend to use includeAllDependencies

this link does not work.

And, if you suggest this solution, shouldn't it be a part of this PR to satisfy self-containment requirement for SimRel contributions?

[HannesWell]

I recommend to use includeAllDependencies

this link does not work.

Indeed, the link changed with the Tycho 3.0.0 since the doc has a version since then.
This is the new one, for Tycho 3.0, but it is the same for older releases:
https://tycho.eclipseprojects.io/doc/3.0.0/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllDependencies

And, if you suggest this solution, shouldn't it be a part of this PR to satisfy self-containment requirement for SimRel contributions?

I updated this PR to set includeAllDependencies to true for those repos that contain the passage-oshi feature. But I'm not sure if each of your repos is really self-contained at the moment. For example org.eclipse.passage.lic.agreements.model requires org.eclipse.emf.ecore but that is not available in the lic-repo but only in the lbc-repo. I assume you want them to be self contained as composite? In that case that tycho property should not be used because it makes each repo self-contained. Instead I suggest to move slf4j into the org.eclipse.passage.lbc.target.feature and move it to the ldc-repo instead. Because the latter feature is contibuted to SimRel so it is not an issue for the SimRel.

But for example org.eclipse.core.runtime, which is required by org.eclipse.passage.lbc.jetty or org.eclipse.jetty.http required by org.eclipse.passage.lic.jetty also seem to be missing from the Passage repos.

[ruspl-afed]

Only org.eclipse.passage.ldc.repository is contributed to SimRel (LDC, not LBC).
But, we are actively using other Passage update site URLs for a number of use cases and would like to keep them functional.

[HannesWell]

Only org.eclipse.passage.ldc.repository is contributed to SimRel (LDC, not LBC). But, we are actively using other Passage update site URLs for a number of use cases and would like to keep them functional.

Understand. And moving slf4j from the ldc and lic repo to the lbc repo would break the former two?
Because for the reasons mentioned in my previous comment I suspect that ldc and lic are not used/usable without lbc and moving slf4j would therefore not make a difference.
And that is what the current status of this PR is doing.

[ruspl-afed]

I suspect that ldc and lic are not used/usable without lbc

Nope, this is not the case

• LIC is Licensing Integration Components, it contains Passage engine and should not depened on any other components
• LBC is Licensing Backend Components (that requires LIC), it is used for FLS that is not mandatory.
• LDC is PDE integration (that requires LIC) and a part of SimRel (together with LIC)

This is why moving SLF4J from LIC to LBC will make a notable difference

[HannesWell]

I suspect that ldc and lic are not used/usable without lbc

Nope, this is not the case

* LIC is Licensing Integration Components, it contains Passage engine and should not depened on any other components

Maybe I'm using the wrong repositories but for example the passage/updates/release/2.5.0/lic is not self-contained for all features/plug-ins. The following target-definition:

<target name="passage-repos">
	<locations>
		<location includeAllPlatforms="false" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
			<repository location="https://download.eclipse.org/passage/updates/release/2.5.0/lic/"/>
			<unit id="org.eclipse.passage.lic.agreements.feature.feature.group" version="0.0.0"/>
		</location>
	</locations>
</target>

... does not resolve because of those errors:

In a similar way the following target-definition does not resolve:

<target name="passage-repos">
	<locations>
		<location includeAllPlatforms="false" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
			<repository location="https://download.eclipse.org/passage/updates/release/2.5.0/lic/"/>
			<unit id="org.eclipse.passage.lic.execute.feature.feature.group" version="0.0.0"/>
		</location>
	</locations>
</target>

I have not checked all IUs from that repo but at least some seem not to be installable without other repos.

However if you prefer to keep slf4j in the lic and ldc repo I can just add the slf4j plugin and its source directly to the repo definition. So if somebody needs it from one of those repositories, it is available, but not pulled into the SimRel repo because it is not in the feature anymore.

[HannesWell]

The same problematic also applies to the org.apache.logging.log4j in the org.eclipse.passage.lic.equinox.feature. If one for example want's to use a more recent version of log4j from Maven-Central, but uses this feature. That feature pulls in the 'old' version from Eclipse-Orbit.

[HannesWell]

@ruspl-afed can we please proceed here as well?

[HannesWell]

Any updates on this one?

[ruspl-afed]

Currently I don't have strong arguments against this one and we still have some room to test and revert it if things go wrong.

[HannesWell]

Thank you.