|
| Re: Info on fragments implementation? [message #46263 is a reply to message #46231] |
Sat, 08 January 2005 01:50   |
Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
Except the code, there is not much documentation. The final doc will be
the R4.0 of the osgi spec which is not due before later this year.
> So, what happens when a fragment is installed for a plugin which is
> already loaded and active?
It is not taken into acccount until the host bundle is refreshed (which
will trigger a restart of the bundle and dependent).
> When a plugin and several of its fragments all contain different
> versions of the same class name, which one is used?
Jars from the host bundle are searched first, then the fragments are
searched (I believe they are consulted in their installation order).
Note that there is trick that you can play:
the bundle declares that it has a jar, but does not actually provides
it and let the fragments provide it. This way a fragment can "hide" a
class from its host.
> Can adding a fragment to a plugin alter the set of things that plugin
> exports (like packages) as seen by other plugins which depend upon it?
I don't think I understood your question, but I'll try an answer:
fragments can declare export and import of packages which therefore
may alter what is visible
> Is there some service or other programmatic means by which a fragment
> can be attached to a plugin? By that plugin's own activator?
No. No. fragments declare in their manifest to which plugin they can
be attached, that's it.
> Is there any other way for a plugin to have a dynamic exported package
> list? Perhaps using PackageAdmin or some other service?
The set of export can not be changed dynamically.
> I'm interested in creating a dynamic library plugin, where the set of
> exported jars may not be known ahead of time. For example, they might
> come from the network. Would fragments be a way to achieve this?
Will the jars coming from the network contains API or just
implementation?
HTH,
PaScaL
|
|
|
| Re: Info on fragments implementation? [message #46290 is a reply to message #46263] |
Fri, 14 January 2005 15:57 |
 Joel Kamentz
Messages: 30
Registered: July 2009 |
Member |
|
|
Email kept bouncing, so I'll post.
On Fri, 07 Jan 2005 20:50:50 -0500, Pascal Rapicault
<pascal@ibm.canada> wrote:
>Except the code, there is not much documentation. The final doc will be
>the R4.0 of the osgi spec which is not due before later this year.
>
>
>> So, what happens when a fragment is installed for a plugin which is
>> already loaded and active?
>It is not taken into acccount until the host bundle is refreshed (which
>will trigger a restart of the bundle and dependent).
It's been a little while since I looked at the source. What do you
mean by refreshing the host bundle? What triggers it? Or are you
talking about the UpdateConfigurator automatic scan the next time
Eclipse starts up?
>> When a plugin and several of its fragments all contain different
>> versions of the same class name, which one is used?
>Jars from the host bundle are searched first, then the fragments are
>searched (I believe they are consulted in their installation order).
>Note that there is trick that you can play:
> the bundle declares that it has a jar, but does not actually provides
>it and let the fragments provide it. This way a fragment can "hide" a
>class from its host.
>
>> Can adding a fragment to a plugin alter the set of things that plugin
>> exports (like packages) as seen by other plugins which depend upon it?
>I don't think I understood your question, but I'll try an answer:
> fragments can declare export and import of packages which therefore
>may alter what is visible
>
>> Is there some service or other programmatic means by which a fragment
>> can be attached to a plugin? By that plugin's own activator?
> No. No. fragments declare in their manifest to which plugin they can
>be attached, that's it.
>
>
>> Is there any other way for a plugin to have a dynamic exported package
>> list? Perhaps using PackageAdmin or some other service?
> The set of export can not be changed dynamically.
>
>> I'm interested in creating a dynamic library plugin, where the set of
>> exported jars may not be known ahead of time. For example, they might
>> come from the network. Would fragments be a way to achieve this?
> Will the jars coming from the network contains API or just
>implementation?
The idea would be to have extra content coming from the network. This
is simpler if the initial version of the plugin can be basically
empty, and outside factors determine its entire content and export
lists. (In other words, the main plugin exports no packages at all,
but the fragments might contribute and export API?)
The idea is sort of to have a generic plugin which can do the external
communication and make it data driven. Some of the configuration data
for what it loads might be included in the plugin, or it might be
completely separate (but likely cached). The actual class content,
etc. would be external to the plugin (coming from the network and
cached somewhere locally), but I would like it to appear as if the
plugin were the source.
Perhaps think of it as a proxying network loader plugin? The list of
what to load could come from anywhere -- maybe even a preferences
page. But the content specified is then exported to other plugins
which list this plugin as a dependency.
Well, that's the idea, anyway.
>HTH,
>
> PaScaL
Joel
|
|
|
Powered by
FUDForum. Page generated in 0.02971 seconds
] 
Search
Help
Register
Login
Home
