Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re: [equinox-dev] Package access across plug-ins... 
Thomas,

 Let me try and be a bit more formal about the description of my issues:

If I have a host plug-in "plugin.host" and a fragment called "plugin.frag".

plugin.host has an output directory of "bin/classes" and plugin.frag has
an output directory of "bin/test-classes", then
When given "plugin.host" to DevClassPathHelper, I get back "bin/classes". I'm reasonable sure that if I passed int "plugin.frag" to DevClassPathHelper I would get back "bin/test-classes" (if it doesn't, I can just inspect the property file myself). So when I start using Bundle.findEntries(...), if the plugin.host and plugin.frag have the same output directories, my current code works. If plugin.host and plugin.frag my current code fails, as I never find the classes "bin/test-classes".
An extension point added to "plugin.frag", reports itself as contributed via "plugin.host", there is no way I can find to get the name "plugin.frag" out of the system using the string "plugin.host" as a starting point. The bundle for "plugin.host" appears to have no interfaces for providing you back the fragments that have been attached.
What I meant by "connecting", was the possibility of listening to bundle startups via the Plug-in Activator (I believe with any bundle or bundle context you can register a listener). If I observed all of the startups, it might be possible thru public calls to receive the name "plugin.frag". From that point, build a data structure that associates "plugin.frag" with it's host "plugin.host". This way, when I start searching for classes available thru the "plugin.host", I'll know to call DevClassPathHelper with the bundle identifier for the host and all of it's fragments (in this example plugin.host and plugin.frag). 

Hopefully this is a clear description of the issues I am facing.

       Kirby



From: Thomas Watson <tjwatson@xxxxxxxxxx>
Reply-To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Subject: Re: Re: [equinox-dev] Package access across plug-ins...
Date: Mon, 23 Oct 2006 08:47:32 -0500

equinox-dev-bounces@xxxxxxxxxxx wrote on 10/22/2006 09:19:56 PM:

> Jeff,
>
>    Well, I feel stupid, I have attempted to reconstruct this with a
trivial
> example I could upload, and I can't.  I'd swear it was broken, but it
has
> since started working.  Using the commands you gave me, I managed to get
my
> plug-ins and fragments working together in the example I really care
about.
> So that was very helpful.
>
>    Now, I'm having problems, because the helpful suggestions about using

> DevClassPathHelper are less useful with fragments.  The
DevClassPathHelper
> doesn't report back the directories used by the fragment, but the
Extension
> Point successfully hides bundle-id of the fragment.  So I can't use the
> osgi.dev properties file to look it up without getting the bundle id of
the
> fragment from somewhere.
>    The fragments are inside of the AbstractBundle, but it's hidden
behind a
> protected accessor.
>
>     If the fragment and the plug-in use the same directories it all
works
> (because overlay of bundles works great), but if the fragments use a
> different directory it all stops working.

I'm not sure what you mean by "same directories".  Do you mean the output
folders you specify for the source folders of your projects (e.g. bin/)?
The framework should be able to handle fragments having different output
folders than their hosts.  If it is not handling this correctly then there
is a bug.

What do you mean by stops working, do you get class loading errors or
package access errors etc.?  Can you create a sample host and fragment
project which we can use to reproduce your problem?  You should be able to
do everything you need to with a fragment without using any internal API's
of the Equinox framework.

> I'm getting fairly close to just
> using an extension point to enumerate the directories by hand.  I can
fix up
> the auto-detection later if I find it a good way to do it.
>
>     A BundleListener might be useful, as performance isn't very
important.
> If you can connect a fragment to the host bundle thru public methods, it

> might work out.

Your fragments should be treated and any other fragment and get
automatically attached to your host bundle.  There is no need to use API
to connect a fragment to a host yourself.

Tom.


>    Just wanted to be sure and say thank you for all of your help, you
guys
> have been very helpful in getting my little project on track.
>
>     Thanks,
>         Kirby
>
>
>
> >From: Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
> >Reply-To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> >To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> >Subject: Re: Re: [equinox-dev] Package access across plug-ins...
> >Date: Sun, 22 Oct 2006 14:35:08 -0400
> >
> >Kirby wrote on 10/22/2006 02:18:59 PM:
> >
> > > My current problem is finding a
> > > canonical way to say "Always load this fragment".
> > >
> > >    Right now, I'm using:
> > > (| (osgi.ws=gtk) (!(osgi.ws=gtk)))
> > >
> > > Which is a tautology, it's just not as obvious as I'd like it to be.
> > > Leaving it blank causes it to filter out, not filter in.  It works
just
> >fine
> > > on my "win32" platform.  If anybody has an answer for that, it'd be
> >worth
> > > knowing about.  I'm trying to track down the code that does the
parsing
> > > right now.
> >
> >Hmmm, this feels like a bug/issue to me.  To clarify, are you saying
that
> >if you omit the Eclipse-PlatformFilter header from the fragment
manifest
> >that the fragment is somehow disabled?  If so, please run with -console
> >and use "ss" and "diag NN" where NN is the bundle id number of the
> >fragment bundle.  The fragment should be RESOLVED and should show the
host
> >bundle id as "master".  If it is just INSTALLED then diag should say
why
> >it is not RESOLVED.  It may be worthwhile opening a bug report if the
> >fragment really is not getting resolved.
> >
> >Jeff
>
>
> >_______________________________________________
> >equinox-dev mailing list
> >equinox-dev@xxxxxxxxxxx
> >https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _________________________________________________________________
> Get FREE company branded e-mail accounts and business Web site from
> Microsoft Office Live
> http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev




_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_________________________________________________________________
Get today's hot entertainment gossip http://movies.msn.com/movies/hotgossip?icid=T002MSN03A07001

Back to the top