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]
