Static weaving version mismatch

[sabberworm]

I was trying out the SPI Fly static weaving method but I ran into an issue: the processed bundle would declare a dependency on the org.apache.aries.spifly package with version specification [1.1.0,1.2.0) (meaning 1.1.x is allowed).

The static weaving tool I was using was at version 1.3.7 (the latest available) and I assumed the static weaving bundle should be at the same version. Since this is newer than 1.1.x, the dependency is never satisfied.

This PR ensures the Export-Package version of the static weaving bundle is read from the same packageinfo file that the tool uses for the Import-Package instruction of the weaved bundle.

[timothyjward]

I assume no one bothered to update the packageinfo properties file when bumping the version but maybe I’m misdiagnosing the issue.

The version of the package and the version of the bundle are not usually synchronised. The version of the package would only be updated if the package contents had changed in a visible way. In this case I believe that 1.1.x probably is the correct package version.

This PR bumps the version in packageinfo but it will also assume semantic versioning for the SPI Fly static weaving bundle

I don’t believe that this matches the intended design for the weaving. My understanding is that the generated import should be extremely restricted so as to guarantee class space consistency with the weaver.

[sabberworm]

So that means I should use the static weaving bundle version 1.1.x even though my bundle was built with the tool version 1.3.7 and there actually is a static weaving bundle version 1.3.7 available?

[sabberworm]

Or is the problem that the static weaving bundle at its POM version 1.3.7 mistakenly exports the package also at version 1.3.7 when it should export 1.1.x?

[timothyjward]

Or is the problem that the static weaving bundle at its POM version 1.3.7 mistakenly exports the package also at version 1.3.7 when it should export 1.1.x?

This seems the more likely culprit, but you’ll need one of the current maintainers to confirm.

[sabberworm]

This seems the more likely culprit, but you’ll need one of the current maintainers to confirm.

Ah, that also makes sense.

I changed the PR to do that instead. Could you take another look?

[sabberworm]

I tried using the ${parent.basedir} placeholder to make the lookup dynamic but it seems placeholders are not supported here.