I gave it another try and it's working now for my RepositoryBrowser. I need to check how I can interface with the IProgressMonitor fro the lazy loading.
Thanks for your help --Toni David Savage wrote: > > Hi Toni, > > Yep I've been thinking of refactoring this but haven't found a good > alternative for the frankly extremely useful IPath and > IProgressMonitor classes. Actually eclipse are very good citizens in > this respect as you can get hold of these base classes via the > following bundle: > > http://download.eclipse.org/releases/ganymede/plugins//org.eclipse.equinox.common_3.4.0.v20080421-2006.jar > > I've created an issue for this [1] but I guess the question is are > there any alternative impls out there. I guess we could also define > our own helper classes for sigil which mirror this functionality but > this seems to be missing the point in modularization somewhat? > > In sigil-ivy I've set up the build such that it downloads these > dependencies on the fly from eclipse.org so apache doesn't have to > host the bundle. In eclipse the classes are obviously already there. I > guess there's a question mark about how to get this bundle into a > netbeans environment though - can netbeans download arbitary jars as > part of a plugin install? > > Regards, > > Dave > > [1] https://issues.apache.org/jira/browse/FELIX-1509 > > On Thu, Aug 20, 2009 at 1:05 PM, eppleton<[email protected]> wrote: >> >> Hi David, >> >> I've implemented a RepositoryManager for my RepositoryBrowser. I was >> looking >> into using a IRepositoryVisitor implementation for getting hold of the >> Bundles but it seems that the ISigilBundle Interface depends on some >> eclipse >> classes for progressmonitoring. Is there a way around these dependencies >> in >> Sigil? >> >> --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-tp24931883p25060806.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-tp24931883p25075916.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]
