Hi Jason,
Jason van Zyl wrote:
On 11 Dec 06, at 9:10 PM 11 Dec 06, Scott Lewis wrote:
Hi Jason,
Jason van Zyl wrote:
So m2eclipse *does* depend upon the Maven embedder currently...and at
the moment there is no way to use the meta info in manifest.mf,
plugin.xml, (and read/changed in memory in the PDE) to 'build' a pom
representationand have the Maven embedder operate on it/with it.
No, waiting for the state resolver to drop out and then I can make a
project builder that attempts to make use of it for doing OSGi/Eclipse
Plugin work. So when that happens we can give that side of it a whirl.
There's all sorts of other interesting things to worry about in the
meantime like integrating Archetypes (basically taking the work Milos
has done for Netbeans), Maven SCM, project bootstrapping (or workspace
materialization I think Buckminster calls it) all of which will be of
interest to Maven users. Eugene is not happy with the extension in its
current state but when he is I would like to bring it here along with
the IDEA integration, and I'm working with Milos/Netbeans to bring the
Netbeans integration here as well.
Very good.
I think it's a terrific/necessary idea to reuse the classpath (and
other meta info/dependency info) within Eclipse itself, as trying
to/rewriting/keeping in synch all of that code (to parse
manifest.mf, .classpath, .project, plugin.xml, feature.xml,
site.xml) would really be a waste since Equinox and PDE does this
already (as it obviously has to).
It would be nice unfortunately stuff needs to be unified on the
Eclipse side first so Jeff said he would help facilitate that with
Tom on the resolver side and Wassim(sp?) on the container side.
What needs to be unified on the Eclipse side first?
Jeff said that versions of the State resolver are used in various
incarnations in several places and the within Eclipse land he would
like to unify this
What is the State resolver? 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.
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...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?
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.
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.
Thanksinadvance,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
