Hi Tony, So the good news is the OBR format is already integrated with the sigil resolver. There are two paths via which the resolver is used in sigil at the moment - either from the ivy build or the eclipse workspace.
The class org.apache.felix.sigil.ivy.BldRepositoryManager loads the repositories specified in a properties file format, using an abstracted RepositoryProviderFactory pattern to load various instances of factories (obr, file, workspace). To see an example of this take a look at the file: $felix-trunk/sigil/bldcommon/sigil-repos.properties In eclipse the class to look at is org.apache.felix.sigil.eclipse.internal.repository.eclipse.SigilRepositoryManager which takes it's configuration from the eclipse preferences and does similar tricks with loading repository providers, though this time the providers are installed via eclipse extension points. To see examples of the repository in use you could look at: org.apache.felix.sigil.ui.eclipse.ui.views.resolution.BundleResolverView // draws a graph of bundle dependencies org.apache.felix.sigil.ui.eclipse.ui.views.RepositoryViewPart // draws a table of bundles in a particular repo org.apache.felix.sigil.eclipse.model.util.JavaHelper.resolveClasspathEntrys // builds up an eclipse classpath based on resolution of bundles from repository The conversation regarding resolvers is referenced here: http://www.mail-archive.com/[email protected]/msg10880.html No actual code has moved yet, but the general gist of the conversation was that it would be "nice" to be able to reuse a common fast OSGi resolution algorithm in the development, deployment and runtime parts of the osgi lifecycle. Hope that's of help... Regards, Dave On Tue, Aug 18, 2009 at 1:42 PM, eppleton<[email protected]> wrote: > > Hi David, > > I'm now at a point, where I want to integrate a repository browser similar > to the Eclipse RepositoryBrowser to my tool ( > http://eppleton.sharedhost.de/blog/?p=867 ). So I'm trying to decide which > approach to use and I'm seeking your advice. > > One possible solution would be to use the Sigil resolver for this. Could you > give me some pointers how this is implemented for Eclipse? > > I'm also thinking about using the OSGi obr API. Again, I haven't worked with > those yet and I've been looking around the web for some pointers but found > nothing. Is there a spec somewhere about the OBR format and some > explanations on the API (the API doc is quite cryptic :-)). You mentioned a > discussion going on about resolvers. Could you provide a link to this > discussion? > > > --Toni > > > > David Savage wrote: >> >> On Wed, Aug 12, 2009 at 2:23 PM, eppleton<[email protected]> wrote: >> >> In sigil we have built a resolver that understands this model and can >> navigate around various abstracted repository providers (currently >> just file system and obr) to pull the relevant OSGi artifacts that >> satisfy build dependencies. There is another conversation on going at >> the moment regarding potential pooling of resources and reusing either >> the Felix runtime resolver or the OBR resolver or some super set of >> all of these to do really fast resolution of hard problems like uses >> (which for the time being the sigil resolver neatly ignores) >> >>> >>> Do you have bnd file support, or are you creating the Properties for bnd >>> on-the-fly? >> >> We have our own file format, though it is very similar to BND in that >> it is just a simple properties file vs an xml file, the main reason >> for this being that it makes it easier to edit the file outside of the >> IDE environment. Currently we parse this file and generate bnd >> instructions based on the project environment (i.e. we support >> inheritance of properties from parent projects - which saves all the >> leaf nodes declaring boilerplate headers and version ranges). >> >>> >>> I'll start working on this part as soon as I've got my admin tool >>> running. >> >> No probs, talk later ;) >> >> Regards, >> >> Dave >> >>> >>> Cheers >>> >>> --Toni >>> >>> >>> David Savage wrote: >>>> >>>> Hi Toni, >>>> >>>> So Sigil is new here at Felix too, we're currently in a migration >>>> phase at the moment as this used to be hosted at >>>> http://sigil.codecauldron.org, but there's some docs here: >>>> >>>> http://felix.apache.org/site/apache-felix-sigil.html >>>> >>>> and I've set up a bunch of issues here: >>>> >>>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310100&component=12312962&resolution=-1&sorter/field=priority&sorter/order=DESC >>>> >>>> I have sigil to a stage where it can build itself - i.e. resolve >>>> dependencies from external repositories based on import/require OSGi >>>> meta data and compile and build the bundles to then be manually >>>> installed in eclipse. There's currently no netbeans integration mainly >>>> due to bandwidth but the underlying model is pretty portable as it can >>>> be used in both ivy and eclipse environments. >>>> >>>> The plan at the moment for the debug support is to use the Felix >>>> launcher which is now able to launch any other OSGi framework via the >>>> new OSGi 4.2 launcher api - of course there's still work to plugin the >>>> process control to the IDE and visualise the various options for OSGi >>>> launching. >>>> >>>> Feel free to post questions here or on the dev mailing list if you're >>>> interested in getting involved :) >>>> >>>> Regards, >>>> >>>> Dave >>>> >>>> On Wed, Aug 12, 2009 at 11:43 AM, eppleton<[email protected]> wrote: >>>>> >>>>> Hi David, >>>>> >>>>> no this is the first time IM on this list. Sure, maybe we can join >>>>> forces. >>>>> Do you have a thread for this? >>>>> >>>>> --Toni >>>>> >>>>> >>>>> >>>>> David Savage-3 wrote: >>>>>> >>>>>> Hi Toni, >>>>>> >>>>>> Sorry off topic from your question but, just wondering if you've seen >>>>>> sigil here on felix, which is attempting to build a common set of osgi >>>>>> developer tools. I'm currently looking runtime support in eclipse >>>>>> wondering if you'd be interested in joining forces to work on netbeans >>>>>> integration? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>>> On 12 Aug 2009, at 10:10, eppleton <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Is there a way to get the classes of the OSGi API and the Felix >>>>>>> implementation in two separate JARs? >>>>>>> >>>>>>> I'm creating a plugin for NetBeans to register and administrate OSGi >>>>>>> containers. Felix ist the default, but I want my tool to rely on the >>>>>>> API >>>>>>> only in order to be able to plugin other implementations (e.g. >>>>>>> Knopflerfish). So the UI can display information for a Bundle >>>>>>> regardless >>>>>>> where it comes from. >>>>>>> >>>>>>> If there's nothing like that out-of-the-box, I'll do it manually. The >>>>>>> question then is: Would that work since it seems I'll also have to >>>>>>> split up >>>>>>> the manifest then... >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> --Toni >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> View this message in context: >>>>>>> http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p24931883.html >>>>>>> Sent from the Apache Felix - Users mailing list archive at >>>>>>> Nabble.com. >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p24933924.html >>>>> Sent from the Apache Felix - Users mailing list archive at Nabble.com. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p24936379.html >>> Sent from the Apache Felix - Users mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > -- > View this message in context: > http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p25024056.html > Sent from the Apache Felix - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
