Le 29 août 2011 à 21:12, Marcel Bruch a écrit : > Hi ivy-users, > > we are currently setting up a large code repository for OSGI bundles. Goal of > this work is to create recommendations models for Eclipse Code Recommenders > intelligent code completion, code search, and extdocs platform (see > http://eclipse.org/recommenders and http://code-recommenders.blogpost.com for > details). The OSGI bundles will be collected from public available Eclipse > Update Sites and should be stored locally using a Maven/Ivy like directory > structure. After the sites have been copied, several analyses will be run to > extract information such as frequent usage patterns, common code snippets etc. > > I just learned that since 2.3. Ivy has support for dealing with OSGI > dependencies such as import packages etc. which is really big news! Since > documentation is a bit rare yet, I'd like to ask you for little information > what can be done with Ivy 2.3: > > 1. Is it supported to copy/mirror an Eclipse P2 repository into a local Ivy > repository?
I have successfully made Ivy read a Eclipse P2 repository in order to download its jars, like any other jar repository, but nothing more. The pieces should be there to do the complete copy chain though. > 2. Is there a simply way to create an Ivy file from an existing OSGI-bundle > manifest? There's an Ant task: http://ant.apache.org/ivy/history/trunk/use/convertmanifest.html > 3. How well is resolving OSGI dependencies supported? Are there any known > limitations I should be aware? Here is a complete view of how OSGi dependencies are mapped to Ivy ones: http://ant.apache.org/ivy/history/trunk/osgi/osgi-mapping.html Thus you can find which OSGi metadata is supported and which is not. Then about the resolve algorithm: compute the best set of jars considering the "requirements" and the availables jars. I think it should work on most cases (I hope, it's experimental, not well tested). There 2 cases Ivy won't be able to resolve as smart an a pure OSGi engine: - having several different versions of the same jar which live in the same OSGi environment, Ivy won't support that (ever, unless a tremendous refactoring in Ivy). - an import package has to be resolved against an implementation. Ivy don't do anything smart, it takes the first which fits. And if the choice makes the resolve fail (because by transitivity there's some conflict), it won't be able to trackback to that choice and try another. It will just fail. It might be quite complicated to make Ivy support that. Then any feedback on some successful (or unsuccessful, but let's be optimistic :) ) use of OSGi features of Ivy will be more than welcomed. Nicolas
