Fix broken OSGi Declarative Service definition files of different Registry implementations

[HannesWell]

In the current master build starting an Eclipse application that contains the bundle org.eclipse.passage.loc.licenses.core or org.eclipse.passage.loc.products.core fails with the error below and the LicenseDomainRegistry, ProductDomainRegistry and ProductOperatorServiceImpl cannot be obtained as OSGi service because their DS component description files need to reference scr-v1.3.0 instead of only 1.1.0.

org.osgi.service.component.ComponentException: Component org.eclipse.passage.loc.internal.licenses.core.LicenseDomainRegistry validation failed: Field reference requires DS >= 1.3
    at org.apache.felix.scr.impl.metadata.ComponentMetadata.validationFailure(ComponentMetadata.java:1101)
    at org.apache.felix.scr.impl.metadata.ReferenceMetadata.validate(ReferenceMetadata.java:729)
    at org.apache.felix.scr.impl.metadata.ComponentMetadata.validate(ComponentMetadata.java:994)
    at org.apache.felix.scr.impl.BundleComponentActivator.validateAndRegister(BundleComponentActivator.java:445)
    at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:407)
    at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:283)
    at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:218)
    at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:612)
    at org.apache.felix.scr.impl.Activator.access$200(Activator.java:75)
    at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:480)
    at org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196)
    at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169)
    at org.apache.felix.scr.impl.AbstractExtender.addingBundle(AbstractExtender.java:139)
    at org.apache.felix.scr.impl.AbstractExtender.addingBundle(AbstractExtender.java:49)
    at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:477)
...

Fixes https://github.com/eclipse-passage/passage/issues/1364.

[HannesWell]

Just relying on the generated DS-component files as implemented in https://github.com/eclipse-passage/passage/pull/1363, would avoid such errors in the future.

[eparovyshnaya]

@HannesWell I have several enquiries for your request.

1. Did not find a ticket for it. It's mandatiry for very much obvious reason: reading this request it is impossible to understand, what is the problem and how to get it. There should be some repeatable explanation as to how and when this failure appears.

2. All the changed files are generated. There is no use in fixing them manually - they will be regenerated automatically to the same state they are now.

3. There are much more OSGi component xml-declarations in Passage. Why did you choose only these three?

[HannesWell]

1. Did not find [a ticket](https://github.com/eclipse-passage/passage/blob/master/CODE_OF_CONDUCT.md) for it. It's mandatiry for very much obvious reason: reading this request it is impossible to understand, what is the problem and how to get it. There should be some repeatable explanation as to how and when this failure appears.

That's right, I just created a PR since the fix seemed obvious to me and I assumed that no discussion will be necessary. Having an extra issue that is just opened with the same description of this PR and closed when this PR is merged seems just overhead, I have elaborated more on this in https://github.com/eclipse-passage/passage/pull/1363#issuecomment-2118823830. But if you prefer to have an extra issue I can create one with the same description as this PR.

If the description is not clear, please let me know. But if you start an Eclipse app with the current master that contains org.eclipse.passage.loc.licenses.core or org.eclipse.passage.loc.products.core you can easily reproduce it.

2. All the changed files are _generated_. There is no use in fixing them manually - they will be regenerated automatically to the same state they are now.

That's right they should not be fixed manually, but at the moment the files in git have not been regenerated after recent changes in Passage. So I didn't fixed them manually but just re-build the affected bundles and their DS component XML files. If you checkout the current Passage master and re-build the workspace you will see the same changes (and a few more but I left out the changes without visible effect. See my comment above).

To avoid such discrepancies in the future and avoid the need to keep them in sync I created https://github.com/eclipse-passage/passage/pull/1363.

3. There are much more OSGi component xml-declarations in Passage. Why did you choose only these three?

Because the other ones are not broken.

[eparovyshnaya]

@HannesWell

Having a ticket for PR is mandatory in this project. The whole collaboration could grow lighter if you come to respect Passage development rules.

In the ticket please place a feasible and repeatable explanation on how to gain the failure.

[HannesWell]

In the ticket please place a feasible and repeatable explanation on how to gain the failure.

See https://github.com/eclipse-passage/passage/issues/1364. As mentioned there and in the initial comment, the error occurs if you just launch an Eclipse application, like the Passage operator, that contains the org.eclipse.passage.loc.licenses.core or org.eclipse.passage.loc.products.core from the current master (and a clean git staging area).

[HannesWell]

@eparovyshnaya, @ruspl-afed now that a ticket exists I hope this can be resolved quickly, at least before the 3.0.0 release. Otherwise the mentioned component are unusable for 3.0.0 and I have to admit I don't understand how this can be unnoticed until now.

[ruspl-afed]

@HannesWell thank you for focusing our attention on this issue! I believe I have now found what may be the reason for the initial discrepancy between the component code and the manifest. We are working to deliver the fix with the nearest 3.0.0 milestone.

[eparovyshnaya]

Fix for the corresponding issue (#1364) is fixed by #1377