search

ctron / package-drone

An OSGI first software artifact repository – Moved to the Eclipse Foundation
https://github.com/eclipse/packagedrone
Eclipse Public License 1.0
39 stars 13 forks source link

bad handling for bundles with system.bundle dependency #104

Closed afischer211 closed 9 years ago

afischer211 commented 9 years ago

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): `

  <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): `

` 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 commented 9 years ago

Can you provide a fix for version 0.9.4?

afischer211 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.

ctron commented 9 years ago

So I made a quick test:

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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