On 12/12/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 11 Dec 06, at 10:25 PM 11 Dec 06, Scott Lewis wrote: > Hi Jason, > > > What is the State resolver? Dependency resolver. Basically a state machine that consumes OSGi dependency information, determines what's missing and asks for more. How the conditions are satisfied is up to the implementation and I believe this is what varies across usage. This is what I was going to try and plug into Maven to make it understand OSGi dependencies. > Is this a name for the PDE code that manages the meta info for a > plugin/feature (e.g. manifest.mf, plugin.xml, etc)? To your > knowledge is there a PDE and/or platform bug against this > particular need/use case? If so, what is it? I did a quick search > for 'state resolver' in Eclipse classification, but nothing that > sounded like what you are describing came up. > I have no idea what's in there. I've always just chatted with Jeff about it. >> >>> The PDE currently does all this and the Jeff is the lead for the >>> Equinox team (which also includes Pascal Rapicault, one of the >>> PDE developers along with others connected with the Equinox >>> team). As far as I know doesn't have any outstanding work items >>> to do anything specific to unifying things for Maven. >> >> It's not for Maven, it's something that would benefit Eclipse and >> Maven would be a by product beneficiary. I asked "where's the >> code", to which he replied "well, in several places". So in order >> for us to consume it there would have to be something concrete we >> could use. What Eugene has now is workable for non-OSGi developers >> but won't cut it otherwise. >> >>> I'm meeting/seeing Jeff on Wednesday am at foundation BOD >>> meeting, so if there is some required change to the PDE or >>> Equinox then I would be happy to speak with him about it >>> directly. But I would need to understand what exactly was >>> required of them and why, as I have spoken with Jeff about Maven >>> integration before. >> >> Unify your State resolver code so we can use it. That's it really. > > I'm just trying to understand this...what would it mean in > refactoring/code restructuring terms to 'unify the state resolver > code'? I believe that the code that parses the plugin and feature > models (i.e. the inter-bundle and inter-feature dependency > information in manifest.mf, plugin.xml, feature.xml, etc) is likely > spread across multiple bundles/plugins, but I believe the > buckminster folks are using these APIs successfully... Information from a manifest or a plugin.xml can be sources for the state resolver from what Jeff has explained to me. The State resolver is something is tuned into OSGi dependency conventions. The version Jeff tried to put together for me came out of Equinox. Where all the variants live I don't know. I'll go to Ottawa one of these days and just find out! :-) > and of course the PDE is doing so...so I don't think it's > 'internal' API (although it could be). Would unification in > practice mean putting this code in a single API/package/bundle? Or > is there something else about this that I'm missing? I think that's what Jeff is talking about. > > One point though...since Equinox is an implementation of OSGi, and > Eclipse plugins and features have meta-information *beyond* what > OSGi defines by spec, I imagine that there has to be at least a > bundle-level separation between (e.g.) bundle dependency info in > manifest.mf...which is read/used by the Equinox platform, and > feature-level dependency info (in feature.xml) that is read/used by > the PDE. I would imagine this is accounted for because the code I saw came from Equinox. Not sure if there is any distinction between OSGi-ness and Eclipse-ness in there. But it would be useful as I would like to account for straight-up OSGi development that is not Eclipse related. People using IDEA or Netbeans might be doing OSGi work. > > If there is a description of what you mean by 'unify state resolver > code' then please let me know where it is and I'll examine. If you're going to talk to Jeff I'm sure he can explain where all this stuff lives in Eclipse-land how best it would tied together for external use for something like Maven. I just know what it's supposed to do, not the mechanics of how folks in Eclipse-land would all use the same code in addition to giving clients a single package to use. Jason.
This message (1) on pde-build-dev contains the state resolver as an attachment. I used this to calculate access rules for the JDT compiler, and to generate POMs for bundles. http://dev.eclipse.org/mhonarc/lists/pde-build-dev/msg00262.html
> > Thanksinadvance, > > Scott > > > > --------------------------------------------------------------------- > 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
