bad handling for bundles with system.bundle dependency

[afischer211]

If I upload bundles with dependency to the wrapper system.bundle, the generated metadata for this bundle is bad.

Here an example: a bundle with following manifest-fragment:
Manifest-Version: 1.0 Bundle-Vendor: %Bundle-Vendor.0 Bundle-Localization: plugin Bundle-RequiredExecutionEnvironment: J2SE-1.2 Bundle-Name: %Bundle-Name.0 Bundle-SymbolicName: javax.xml Require-Bundle: system.bundle Bundle-Version: 1.3.4.v201005080400
The fragment of the generated p2-metadata in a classic p2-repository (content.xml):
<requires size='1'> <required namespace='osgi.bundle' name='org.eclipse.osgi' range='0.0.0'/> </requires> <artifacts size='1'> <artifact classifier='osgi.bundle' id='javax.xml' version='1.3.4.v201005080400'/> </artifacts>

And here the problematic fragment of the generated p2-metadata from package drone (also content.xml of the channel):
<requires size="1"> <required name="system.bundle" namespace="osgi.bundle" range="0.0.0"/> </requires> <artifacts size="1"> <artifact classifier="osgi.bundle" id="javax.xml" version="1.3.4.v201005080400"/> </artifacts>
There seems to exist a special handling for dependencies to the bundle system.bundle, so the name is mapped to org.eclipse.osgi in the metadatas. This special handling is missing in package-drone.

[afischer211]

Can you provide a fix for version 0.9.4?

[afischer211]

Please remind, that I use the aspect "P2 Metadata Generator 1.0.0 – p2.metadata" for the generation of the needed metadatas. The datas from tycho are cleaned with the aspect "Tycho Cleaner 1.0.0 – tycho-cleaner".

[maggu2810]

Why should Package-Drone replace system.bundle with org.eclipse.osgi?
system.bundle should be a valid dependency: http://wiki.osgi.org/wiki/System_Bundle

[ctron]

WTF ... Well mapping this would be easy, but what when you want to use Apache Felix, Concierge or Knopflerfish?

I think the least that should be possible is to define an alternative bundle name. And still this would let the channel maintainer define which OSGi implementation you have to use.

Guessing that P2 won't work outside of Equinox-World, this might be OK for now. But ... WTF.

I don't want to push new features into the 0.9.x branch. This is what caused troubles in the past. ;-) And I know this regression compared to Tycho or P2. But still, adding a mapping and configuration for this, is an enhancement for Package Drone.

But I will make the release 0.10.0-m2 next week, and add this feature, so that you can switch.

[ctron]

Well I wouldn't use system.bundle either, but when somebody else did and P2 does handle it that way, what can you do?

I would suggest providing a replacement name. Leave it empty for not replacing the alias.

[maggu2810]

Is there a specification how the p2-metadata / context.xml have to be generated?
Shouldn't the name "system.bundle" works, too?

Sure, if this is a must, we should add an option or do it the same way.
But forcing system.bundle to be Equinox OSGi seems strange to me -- also for p2.

[maggu2810]

Isn't this a problem of the plug-in / bundle at all.
If the bundle is using system.bundle it does not depend on the framework.
It the bundle wants to depend on Equinox, it should use org.eclipse.osgi.

[ctron]

Well I think as well that it is odd. In many ways!

If the bundle requires functionality from the system.bundle I, personally, would favor package imports of bundle imports. But I can also imagine that P2 really does replace system.bundle with org.eclipse.osgi, there are a few oddities in P2.

However I could imagine that the P2 system has no clue about the fact that the org.eclipse.osg bundle can also be referenced to as system.bundle since all that P2 care about is IUs (installable units).

So in the end this would be an option (optional) for the P2 metadata generation which has to be activated manually and would, maybe, automatically be set by a recipe. It would also not interfere with Maven or R5 handling.

[ctron]

I just browsed and grepped a little bit through the P2 source code and could not find anything that indicates that their are doing something like this.

However I also did browse and grep through the Tycho source code and saw that their "resolver" does resolve the system.bundle to something else.

So if this information is transformed during build, and this information is then lost and written out in the fragment files, then we would have the described behavior.

However I would consider this a bug in Maven Tycho!

There is one "easy" test you can do. Export the OSGi bundle from the Eclipse PDE to a P2 repository. Or use the P2 ant task to generate a P2 repository from this single OSGi bundle. And check the generated meta data of P2 (without Tycho).

[ctron]

There is a sample project I can direct you to [1], coming from Eclipse SCADA. It is an ant file which generates a local P2 repository from local OSGi files. It is important that the ant file is executed from inside the Eclipse IDE, with the internal Ant runtime. Otherwise the tasks will not be available.

[1] http://git.eclipse.org/c/eclipsescada/org.eclipse.scada.external.git/tree/org.eclipse.scada.external-repo/build.ant

[afischer211]

One suggestion: create a new aspect like the conventional aspect "P2 Metadata Generator 1.0.0 – p2.metadata", but with fixed mapping to org.eclipse.osgi. The name could be "Equinox P2 Metadata Generator".
So the admin can decide, which mapping should be used.
At the moment I can not use any bundle with dependency to system.bundle from package drone. Tycho (version 0.21.0 or 0.22.0) fails with error about unresolved dependency to system.bundle.
I have to deploy these bundle to a filesystem-based P2-repository.

[afischer211]

For deployment to a filesystem-based repository I use the tycho-extras-plugin (https://wiki.eclipse.org/Tycho/Additional_Tools#publish-features-and-bundles_goal).
May be the mapping is done inside this plugin?

[afischer211]

According http://wiki.osgi.org/wiki/System_Bundle I agree, this is a bug in Tycho. But I hope, you can solve this Tycho-bug with a "special" aspect for package-drone?

[maggu2810]

To get your stuff working (I think we all would like to get your stuff running), we need to change something.
But we should think about an optimal solution.

• Is it a bug in Tycho?
• Will all working, if you create a dummy bundle "system.bundle" that requires the package "org.eclipse.osgi"?
• Should we fix the bug (if it is one) in the Tycho plugin and let's see what the maintainer of Tycho talks about it?
• Another channel aspect, that does the same with one change of the system.bundle handling, seems not the best solution for me.
• Perhaps we could add a configuration to the current aspect how the system.bundle is processed: keep it unchanged (this should be the default option), replace it to <add_a_textfield_for_an_user_value> (we could add examples in the description for Equinox, Felix, ...

[ctron]

So I made a quick test:

• Create a new bundle
• Add a dependency to `system.bundle'
• Create a new feature and add the bundle
• Export the bundle using the Eclipse PDE export wizards for features
  • Enable P2 metadata generation

The result is in fact a dependency on org.eclipse.osgi:

…
   <requires size='2'>
     <required namespace='osgi.bundle' name='org.eclipse.osgi' range='0.0.0'/>
     <required namespace='java.package' name='org.osgi.framework' range='1.3.0'/>
   </requires>
…

[ctron]

Therefore I would consider this as a regression in Package Drone created P2 meta data.

However I would not simply replace this, hard coded, with org.eclipse.osgi but, with a configurable alternative, defaulting to org.eclipse.osgi. Putting in system.bundle as alias, would simply then be possible to keep system.bundle.

[maggu2810]

That sounds reasonable, but is still very confusing to me, why this should be necessary.
But this is not the only strange thing about system.bundle.

[afischer211]

Thanks for your solution. I hope for getting my last problems with productive usage of pdrone (as replacement for file-based P2-repositories in a Tycho-based scenario) solved with the next releases. ;-)

[afischer211]

My tycho-builds runs again with version 0.10.0-m2, so we can close this issue.