That's perfect, I'll use a similar approach to the one you described fo Eclipse. I've already defined an extension point in the NetBeans Layer for registering Repository instances (that's also how I register osgi frameworks), so this perfectly matches my needs!
Thanks for the pointers! --Toni David Savage wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p25025532.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]
