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.
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]
