Wildcards must be supported by the Service Component Header check

[laeubi]

See http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#d0e38069 the header supports wildcards, but currently tycho do not understand them, for example:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:3.0.0-SNAPSHOT:package-plugin (default-package-plugin) on project org.eclipse.e4.core.services: Component definition OSGI-INF/.xml not found! Neither /home/jenkins/agent/workspace/I-build-4.25/eclipse.platform.releng.aggregator/eclipse.platform.releng.aggregator/cje-production/gitCache/eclipse.platform.releng.aggregator/eclipse.platform/runtime/bundles/org.eclipse.e4.core.services/OSGI-INF/.xml nor /home/jenkins/agent/workspace/I-build-4.25/eclipse.platform.releng.aggregator/eclipse.platform.releng.aggregator/cje-production/gitCache/eclipse.platform.releng.aggregator/eclipse.platform/runtime/bundles/org.eclipse.e4.core.services/target/classes/OSGI-INF/*.xml exists

[laeubi]

@tjwatson the spec says:

The last component of each path in the Service-Component header may use wildcards so that Bundle.findEntries can be used to locate the XML document within the bundle and its fragments.

Is there a method Tycho can re-use from the Equinox Framework to parse / match file names like in Bundle.findEntries?

[akurtakov]

@laeubi This is the breakage from https://ci.eclipse.org/releng/job/I-build-4.25/53/console , right? How did it happen to not have happened till now?

[laeubi]

This was added here: https://github.com/eclipse/tycho/commit/43f0716cae1dde52fe24ade650891b8d6b487be6

[akurtakov]

Ah, ok. If you can't fix it today would you please revert the patch till it's fixed so tonight's I-build works.

[akurtakov]

Or is there an improvement that can be done on platform side ?

[laeubi]

if you need a solution now you can disable the strict binary include checks in the build, I think I'll simply skip the check if any wildcards are present for now, but will take some time until fix applied, approved and visible in the snapshots.

[akurtakov]

No need for right now, but hopefully tonight's I-build works.

[tjwatson]

Is there a method Tycho can re-use from the Equinox Framework to parse / match file names like in Bundle.findEntries?

Short of creating an Equinox framework instance and installing the bundles and fragments in it there is no public utility APIs that could be used for implementing findEntries outside of the framework. I was going to mention using the org.eclipse.osgi.container.ModuleWiring.findEntries(String, String, int) because I think Tycho already creates a ModuleContainer instance for other reasons. But that requires you to provide an implementation of org.eclipse.osgi.container.ModuleLoader.findEntries(String, String, int) for the ModuleLoader instances your adaptor returns from org.eclipse.osgi.container.ModuleContainerAdaptor.createModuleLoader(ModuleWiring)

And that pretty much means you still have to implement all that yourself for findEntries.

[laeubi]

@tjwatson thanks this leads me on the right track, I think one ultimately could reuse Storage.listEntryPaths(..) here and providing for example a DirBundleFile.

But on further investigate this i came across some other issue:

1. officially a component.xml might be provided by a fragment, so the question is if it is valid to give an error (even though we name it "strict include checks" if a file is missing. This feature was meant to hep people if the forget adding xmls but you can also "intentionally" not add them, even though I can't really get what should be the usecase, as one still needs to know in advance what are possible components if you list them explicitly.
2. This becomes even more important when using wildcards, where one actually could think of having a generic pattern like in the error OSGI-INF/*.xml where a fragment could provide own components here without the host not need to know about in advance.

I could think about the following that should match most users expectation:

1. If there is a full path, we validate that it is part of the bundle, even though theoretically it could be provided by a fragment I think in such cases we can simply tell people to disable strict checks.
2. If there is a pattern, we try to match that, and print a warning if it matches nothing in strict mode
3. We simply ignore wildcards and do no checks at all...

Any thoughts?

[laeubi]

As it seems there is not much need in wildcard support, I'll close this for now and we can reopen if there is some more interest/real usecase.