Home » Eclipse Projects » Equinox » What happened to Export-Package, etc.?
|
| Re: What happened to Export-Package, etc.? [message #33780 is a reply to message #33440] |
Fri, 16 January 2004 05:05   |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
These are great questions. See my comments...
"Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
news:bu4r67$7lq$1@eclipse.org...
> The MANIFEST.MF generated by PDE includes "Require-Bundle" and
> "Provides-Packages" headers in place of the OSGi "Import/Export-Package"
> and "Import/Export-Service" headers. I understand the need to add extra
> headers to augment the functionality provided by OSGi, but why did you
> choose to remove the OSGi headers. It looks like they can co-exist.
> The effect of excluding the OSGi headers is:
They can and do co-exist. The manifest generator happens to generate
manifests using Require/Provide since those semantics most closely match
what we see in Eclipse. There are instances of Import/Export (and both) in
some of the manifests in Eclipse (see runtime or update.configurator).
> 1) You cannot use the generated MANIFEST.MF if you want to deploy to other
> OSGi implementations.
True today but we are working with the OSGi community to add new dependency
expressions to the spec. OSGi 4.0 may well include support for this style
of bundle dependencies.
> 2) You lose the ability to dynamically swap different implementations of
> services that are packaged in different bundles since you are bound by the
> actual bundles instead of the service interfaces they export.
The standard OSGi Import/Export Package and services mechanism are very
useful/powerful. But it turns out that in many of our (and others)
usecases, you actually don't want to get implementations from others and/or
use services. For example, product guys are absolutely freaked out by the
idea that they could not control the exact implementation constraints. My
sense (no validation) is that OSGi's traditional audience (gateway providers
etc) had much more control over the OSGi installation/configuration than we
see with Eclipse scenarios. Thus, specifying a dependency on a package X
and relying on a system integrator to only make available reasonable
implementations of X makes sense. In Eclipse scenarios the system
integrator is more often than not, the end user. They neither have the
knowledge or interest to deal with this level of detail.
The other thing to note its that not all Eclipse plugins/bundles contain
code. Doc plugins for example supply content to the help system. How can I
express a dependency that particular doc be installed?
> The
> workaround is to package the service definitions in a separate bundle so
> that client bundles are dependent on the definition bundle rather than the
> implemenation bundle(s). However, that can quickly become cumbersome. In
> fact, the OSGi FAQs suggest avoiding this approach. Instead, they suggest
> including the service definition (and resulting dependency graph) in
> whatever bundles require.
May have gotten you wrong but my understanding of OSGi common practice is
that the service APIs are in a bundle by themselves and the implementations
are in other bundles. If you lump the API and the implementation together
then the effects of configuration changes (e.g., updating a bundle) will
propagate much further causing more of the system to shutdown and restart.
>Does Eclipse have a tool for exporting a set of
> classes and the result dependency graph? If so, one could define a common
> base project (not plug-in) and export subsets of it to jars to be included
> in dependent bundles. This would alleviate the need for hardcoding of
> bundle dependencies.
I do not know of such a tool.
> If mapping bundle dependencies is a requirement,
> maybe it could be moved to the encompasing feature project so that the
> dependencies are kept external to the bundle definitions.
Features are not part of the runtime. Of couse, we could make them be but
it is unclear how this would help. If the classloaders look at and follow
the dependencies expressed by the features (as well as the Import/Export
dependencies), you get the same net effect.
Jeff
|
|
|
| Re: What happened to Export-Package, etc.? [message #33977 is a reply to message #33780] |
Fri, 16 January 2004 16:39 |
 Stephen Goldbaum
Messages: 75
Registered: July 2009 |
Member |
|
|
Hey Jeff,
Thanks for all of the answers.
Concerning including the service APIs in the implementation bundle, you
got me right. It's just easier to include the shared interfaces in all of
the bundles that use them than to require a central service definition
bundle (see http://161.58.208.149/devzone/members/faq/index.php#sharing
under the tech faqs on the OSGi DevZone). At least, that's true in highly
dynamic environments where service definitions may come and go. This may
not be true of general RCP usecases.
As far as explicitly placing bundle dependencies in the bundles, keeping
dependency info external to the bundles would allow for more extensible
deployment scenarios. For instance, my project (AppPlugin) uses different
implementations of a certain service for external and internal
deployments. So now I have to create two AppPlugin projects to account
for the different bundle dependencies. If this information were kept
external to the AppPlugin bundle, say in a Deployment project, I could
create keep a single AppPlugin project (since it's a lot of code) and
create two Deployment projects instead.
-Stephen
Jeff McAffer wrote:
> These are great questions. See my comments...
> "Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
> news:bu4r67$7lq$1@eclipse.org...
> > The MANIFEST.MF generated by PDE includes "Require-Bundle" and
> > "Provides-Packages" headers in place of the OSGi "Import/Export-Package"
> > and "Import/Export-Service" headers. I understand the need to add extra
> > headers to augment the functionality provided by OSGi, but why did you
> > choose to remove the OSGi headers. It looks like they can co-exist.
> > The effect of excluding the OSGi headers is:
> They can and do co-exist. The manifest generator happens to generate
> manifests using Require/Provide since those semantics most closely match
> what we see in Eclipse. There are instances of Import/Export (and both) in
> some of the manifests in Eclipse (see runtime or update.configurator).
> > 1) You cannot use the generated MANIFEST.MF if you want to deploy to other
> > OSGi implementations.
> True today but we are working with the OSGi community to add new dependency
> expressions to the spec. OSGi 4.0 may well include support for this style
> of bundle dependencies.
> > 2) You lose the ability to dynamically swap different implementations of
> > services that are packaged in different bundles since you are bound by the
> > actual bundles instead of the service interfaces they export.
> The standard OSGi Import/Export Package and services mechanism are very
> useful/powerful. But it turns out that in many of our (and others)
> usecases, you actually don't want to get implementations from others and/or
> use services. For example, product guys are absolutely freaked out by the
> idea that they could not control the exact implementation constraints. My
> sense (no validation) is that OSGi's traditional audience (gateway providers
> etc) had much more control over the OSGi installation/configuration than we
> see with Eclipse scenarios. Thus, specifying a dependency on a package X
> and relying on a system integrator to only make available reasonable
> implementations of X makes sense. In Eclipse scenarios the system
> integrator is more often than not, the end user. They neither have the
> knowledge or interest to deal with this level of detail.
> The other thing to note its that not all Eclipse plugins/bundles contain
> code. Doc plugins for example supply content to the help system. How can I
> express a dependency that particular doc be installed?
> > The
> > workaround is to package the service definitions in a separate bundle so
> > that client bundles are dependent on the definition bundle rather than the
> > implemenation bundle(s). However, that can quickly become cumbersome. In
> > fact, the OSGi FAQs suggest avoiding this approach. Instead, they suggest
> > including the service definition (and resulting dependency graph) in
> > whatever bundles require.
> May have gotten you wrong but my understanding of OSGi common practice is
> that the service APIs are in a bundle by themselves and the implementations
> are in other bundles. If you lump the API and the implementation together
> then the effects of configuration changes (e.g., updating a bundle) will
> propagate much further causing more of the system to shutdown and restart.
> >Does Eclipse have a tool for exporting a set of
> > classes and the result dependency graph? If so, one could define a common
> > base project (not plug-in) and export subsets of it to jars to be included
> > in dependent bundles. This would alleviate the need for hardcoding of
> > bundle dependencies.
> I do not know of such a tool.
> > If mapping bundle dependencies is a requirement,
> > maybe it could be moved to the encompasing feature project so that the
> > dependencies are kept external to the bundle definitions.
> Features are not part of the runtime. Of couse, we could make them be but
> it is unclear how this would help. If the classloaders look at and follow
> the dependencies expressed by the features (as well as the Import/Export
> dependencies), you get the same net effect.
> Jeff
|
|
|
| Re: What happened to Export-Package, etc.? [message #34053 is a reply to message #33977] |
Fri, 16 January 2004 19:18 |
Sten Ernerot
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Hi
I dont think that "required-bundle" tag is needed during runtime.
If you define Import-Package in your AppPlugin (and Export-Package in your
service) it should work.
Cheers
Sten
"Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
news:bu944p$542$1@eclipse.org...
> Hey Jeff,
>
> Thanks for all of the answers.
>
> Concerning including the service APIs in the implementation bundle, you
> got me right. It's just easier to include the shared interfaces in all of
> the bundles that use them than to require a central service definition
> bundle (see http://161.58.208.149/devzone/members/faq/index.php#sharing
> under the tech faqs on the OSGi DevZone). At least, that's true in highly
> dynamic environments where service definitions may come and go. This may
> not be true of general RCP usecases.
>
> As far as explicitly placing bundle dependencies in the bundles, keeping
> dependency info external to the bundles would allow for more extensible
> deployment scenarios. For instance, my project (AppPlugin) uses different
> implementations of a certain service for external and internal
> deployments. So now I have to create two AppPlugin projects to account
> for the different bundle dependencies. If this information were kept
> external to the AppPlugin bundle, say in a Deployment project, I could
> create keep a single AppPlugin project (since it's a lot of code) and
> create two Deployment projects instead.
>
> -Stephen
>
> Jeff McAffer wrote:
>
> > These are great questions. See my comments...
>
> > "Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
> > news:bu4r67$7lq$1@eclipse.org...
> > > The MANIFEST.MF generated by PDE includes "Require-Bundle" and
> > > "Provides-Packages" headers in place of the OSGi
"Import/Export-Package"
> > > and "Import/Export-Service" headers. I understand the need to add
extra
> > > headers to augment the functionality provided by OSGi, but why did you
> > > choose to remove the OSGi headers. It looks like they can co-exist.
> > > The effect of excluding the OSGi headers is:
>
> > They can and do co-exist. The manifest generator happens to generate
> > manifests using Require/Provide since those semantics most closely match
> > what we see in Eclipse. There are instances of Import/Export (and both)
in
> > some of the manifests in Eclipse (see runtime or update.configurator).
>
> > > 1) You cannot use the generated MANIFEST.MF if you want to deploy to
other
> > > OSGi implementations.
>
> > True today but we are working with the OSGi community to add new
dependency
> > expressions to the spec. OSGi 4.0 may well include support for this
style
> > of bundle dependencies.
>
> > > 2) You lose the ability to dynamically swap different implementations
of
> > > services that are packaged in different bundles since you are bound by
the
> > > actual bundles instead of the service interfaces they export.
>
> > The standard OSGi Import/Export Package and services mechanism are very
> > useful/powerful. But it turns out that in many of our (and others)
> > usecases, you actually don't want to get implementations from others
and/or
> > use services. For example, product guys are absolutely freaked out by
the
> > idea that they could not control the exact implementation constraints.
My
> > sense (no validation) is that OSGi's traditional audience (gateway
providers
> > etc) had much more control over the OSGi installation/configuration than
we
> > see with Eclipse scenarios. Thus, specifying a dependency on a package
X
> > and relying on a system integrator to only make available reasonable
> > implementations of X makes sense. In Eclipse scenarios the system
> > integrator is more often than not, the end user. They neither have the
> > knowledge or interest to deal with this level of detail.
>
> > The other thing to note its that not all Eclipse plugins/bundles contain
> > code. Doc plugins for example supply content to the help system. How
can I
> > express a dependency that particular doc be installed?
>
> > > The
> > > workaround is to package the service definitions in a separate bundle
so
> > > that client bundles are dependent on the definition bundle rather than
the
> > > implemenation bundle(s). However, that can quickly become cumbersome.
In
> > > fact, the OSGi FAQs suggest avoiding this approach. Instead, they
suggest
> > > including the service definition (and resulting dependency graph) in
> > > whatever bundles require.
>
> > May have gotten you wrong but my understanding of OSGi common practice
is
> > that the service APIs are in a bundle by themselves and the
implementations
> > are in other bundles. If you lump the API and the implementation
together
> > then the effects of configuration changes (e.g., updating a bundle) will
> > propagate much further causing more of the system to shutdown and
restart.
>
> > >Does Eclipse have a tool for exporting a set of
> > > classes and the result dependency graph? If so, one could define a
common
> > > base project (not plug-in) and export subsets of it to jars to be
included
> > > in dependent bundles. This would alleviate the need for hardcoding of
> > > bundle dependencies.
>
> > I do not know of such a tool.
>
> > > If mapping bundle dependencies is a requirement,
> > > maybe it could be moved to the encompasing feature project so that the
> > > dependencies are kept external to the bundle definitions.
>
> > Features are not part of the runtime. Of couse, we could make them be
but
> > it is unclear how this would help. If the classloaders look at and
follow
> > the dependencies expressed by the features (as well as the Import/Export
> > dependencies), you get the same net effect.
>
> > Jeff
>
>
|
|
|
| Re: What happened to Export-Package, etc.? [message #34084 is a reply to message #34053] |
Fri, 16 January 2004 20:36 |
Stephen Goldbaum
Messages: 75
Registered: July 2009 |
Member |
|
|
That might be true, but I think the required bundle concept is a good
feature and I'd like to use it. It just seems that if the bundle
dependencies were described externally, it would facilitate more flexible
deployment scenarios. I'm not very familiar with Ecplipse Plugins, but I
thought that's what Features were for.
Of course, you could achieve the same effect in OSGi by placing the bundle
location in the properties of every service registered by that bundle.
Dependent bundles could then filter for services based on this value.
This would be pretty laborious and better left to the build environment.
Sten Ernerot wrote:
> Hi
> I dont think that "required-bundle" tag is needed during runtime.
> If you define Import-Package in your AppPlugin (and Export-Package in your
> service) it should work.
> Cheers
> Sten
> "Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
> news:bu944p$542$1@eclipse.org...
> > Hey Jeff,
> >
> > Thanks for all of the answers.
> >
> > Concerning including the service APIs in the implementation bundle, you
> > got me right. It's just easier to include the shared interfaces in all of
> > the bundles that use them than to require a central service definition
> > bundle (see http://161.58.208.149/devzone/members/faq/index.php#sharing
> > under the tech faqs on the OSGi DevZone). At least, that's true in highly
> > dynamic environments where service definitions may come and go. This may
> > not be true of general RCP usecases.
> >
> > As far as explicitly placing bundle dependencies in the bundles, keeping
> > dependency info external to the bundles would allow for more extensible
> > deployment scenarios. For instance, my project (AppPlugin) uses different
> > implementations of a certain service for external and internal
> > deployments. So now I have to create two AppPlugin projects to account
> > for the different bundle dependencies. If this information were kept
> > external to the AppPlugin bundle, say in a Deployment project, I could
> > create keep a single AppPlugin project (since it's a lot of code) and
> > create two Deployment projects instead.
> >
> > -Stephen
> >
> > Jeff McAffer wrote:
> >
> > > These are great questions. See my comments...
> >
> > > "Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
> > > news:bu4r67$7lq$1@eclipse.org...
> > > > The MANIFEST.MF generated by PDE includes "Require-Bundle" and
> > > > "Provides-Packages" headers in place of the OSGi
> "Import/Export-Package"
> > > > and "Import/Export-Service" headers. I understand the need to add
> extra
> > > > headers to augment the functionality provided by OSGi, but why did you
> > > > choose to remove the OSGi headers. It looks like they can co-exist.
> > > > The effect of excluding the OSGi headers is:
> >
> > > They can and do co-exist. The manifest generator happens to generate
> > > manifests using Require/Provide since those semantics most closely match
> > > what we see in Eclipse. There are instances of Import/Export (and both)
> in
> > > some of the manifests in Eclipse (see runtime or update.configurator).
> >
> > > > 1) You cannot use the generated MANIFEST.MF if you want to deploy to
> other
> > > > OSGi implementations.
> >
> > > True today but we are working with the OSGi community to add new
> dependency
> > > expressions to the spec. OSGi 4.0 may well include support for this
> style
> > > of bundle dependencies.
> >
> > > > 2) You lose the ability to dynamically swap different implementations
> of
> > > > services that are packaged in different bundles since you are bound by
> the
> > > > actual bundles instead of the service interfaces they export.
> >
> > > The standard OSGi Import/Export Package and services mechanism are very
> > > useful/powerful. But it turns out that in many of our (and others)
> > > usecases, you actually don't want to get implementations from others
> and/or
> > > use services. For example, product guys are absolutely freaked out by
> the
> > > idea that they could not control the exact implementation constraints.
> My
> > > sense (no validation) is that OSGi's traditional audience (gateway
> providers
> > > etc) had much more control over the OSGi installation/configuration than
> we
> > > see with Eclipse scenarios. Thus, specifying a dependency on a package
> X
> > > and relying on a system integrator to only make available reasonable
> > > implementations of X makes sense. In Eclipse scenarios the system
> > > integrator is more often than not, the end user. They neither have the
> > > knowledge or interest to deal with this level of detail.
> >
> > > The other thing to note its that not all Eclipse plugins/bundles contain
> > > code. Doc plugins for example supply content to the help system. How
> can I
> > > express a dependency that particular doc be installed?
> >
> > > > The
> > > > workaround is to package the service definitions in a separate bundle
> so
> > > > that client bundles are dependent on the definition bundle rather than
> the
> > > > implemenation bundle(s). However, that can quickly become cumbersome.
> In
> > > > fact, the OSGi FAQs suggest avoiding this approach. Instead, they
> suggest
> > > > including the service definition (and resulting dependency graph) in
> > > > whatever bundles require.
> >
> > > May have gotten you wrong but my understanding of OSGi common practice
> is
> > > that the service APIs are in a bundle by themselves and the
> implementations
> > > are in other bundles. If you lump the API and the implementation
> together
> > > then the effects of configuration changes (e.g., updating a bundle) will
> > > propagate much further causing more of the system to shutdown and
> restart.
> >
> > > >Does Eclipse have a tool for exporting a set of
> > > > classes and the result dependency graph? If so, one could define a
> common
> > > > base project (not plug-in) and export subsets of it to jars to be
> included
> > > > in dependent bundles. This would alleviate the need for hardcoding of
> > > > bundle dependencies.
> >
> > > I do not know of such a tool.
> >
> > > > If mapping bundle dependencies is a requirement,
> > > > maybe it could be moved to the encompasing feature project so that the
> > > > dependencies are kept external to the bundle definitions.
> >
> > > Features are not part of the runtime. Of couse, we could make them be
> but
> > > it is unclear how this would help. If the classloaders look at and
> follow
> > > the dependencies expressed by the features (as well as the Import/Export
> > > dependencies), you get the same net effect.
> >
> > > Jeff
> >
> >
|
|
|
| Re: What happened to Export-Package, etc.? [message #34119 is a reply to message #34084] |
Sat, 17 January 2004 03:37 |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
I think the both use cases for require-bundle are interested and necessary
but are somehow be orthogonal:
- the first case, where the dependencies are defined inside the manifest, is
necessary to allow bundle developers to clearly express the requirements of
their bundles because they are the only one to know them (they may make
strong assumption about their presence).
- the second case, where the dependencies are externalized, is of interest
for a product assembler / system integrator who wants to force a set of
bundles to work together.
Note that for now the RFC 70 (proposed at OSGi) only contains a proposal for
the first aspect.
PaScaL
"Stephen Goldbaum" <stephen.goldbaum@lehman.com> a
|
|
|
| Re: What happened to Export-Package, etc.? [message #34184 is a reply to message #34084] |
Sat, 17 January 2004 18:05 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
I agree with all that is being said here. I see it as a producer/consumer
problem. As the producer of a plugin I want to be able to specify what I
depend on. In OSGi today I can spec the packages I need but not the
implementation. The proposal is to extend that and allow me to spec the
actual bundle (id and version) I require. This allows me to clearly set
expectations and define tested configurations etc.
As a plugin consumer I may well have scenarios in which the producers
assumptions/assertions are invalid. If I am willing to take on the testing
and support load, I should be free to effectively override the declarations
that the producer made.
Our overall direction is to accomodate both of these views. To date we have
only proposed/implemented the producer's point of view. This has been done
by extending the notion of Bundle to include explicit interbundle
dependencies (Require-Bundle).
In the framework spec currently there is no place for one to define the
consumer's point of view. Personally I don't think that the framework
should define another runtime entity for this informaton. Rather, it should
expose API on PackageAdmin (or some such) where someone with a consumer's
viewpoint can specify overrides or additional dependencies. This is input
to the runtime (e.g., package/bundle resolution) but we need not spec how
this information is managed.
OSGi RFP44 contains the notion of "bundle suites". While they have not
really been defined as yet, they appear to be somewhat akin to Eclipse
features. Note that Eclipse featuers are NOT a runtime entity. They are a
delivery mechanism and they do not have the ability to specify or override
interplugin dependencies. It would be interesting to add these abilities to
features/suites but that does not seem like the end of the story. Features
are just another level of component and so again suffer from the
producer/consumer view point problems. So, while it is intresting to spec
dependencies/overrides in features, there is still a need to have global
"configuration" level control.
So rather there creating explicit support for each of these parties at the
core level of the framework, I would prefer to see a general mechanism which
simply takes a set of overrides/dependencies and uses them during
resolution. It would then be up to a configuraiton agent to observe the
data in the features, suites, config data, then prioritize and apply. We
are headed that way with our PlatformAdmin service. It is unclear how far
we will get for 3.0.
Wow, I had a lot to say!
Jeff
, it would be reasonable to add this information. In fact they are defined
by the install/update component for managing collections of plugins/bundles.
I personally very much like this characteristic.
"Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
news:bu9hvs$mpe$1@eclipse.org...
> That might be true, but I think the required bundle concept is a good
> feature and I'd like to use it. It just seems that if the bundle
> dependencies were described externally, it would facilitate more flexible
> deployment scenarios. I'm not very familiar with Ecplipse Plugins, but I
> thought that's what Features were for.
>
> Of course, you could achieve the same effect in OSGi by placing the bundle
> location in the properties of every service registered by that bundle.
> Dependent bundles could then filter for services based on this value.
> This would be pretty laborious and better left to the build environment.
>
>
> Sten Ernerot wrote:
>
> > Hi
>
> > I dont think that "required-bundle" tag is needed during runtime.
> > If you define Import-Package in your AppPlugin (and Export-Package in
your
> > service) it should work.
>
> > Cheers
> > Sten
>
>
> > "Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
> > news:bu944p$542$1@eclipse.org...
> > > Hey Jeff,
> > >
> > > Thanks for all of the answers.
> > >
> > > Concerning including the service APIs in the implementation bundle,
you
> > > got me right. It's just easier to include the shared interfaces in
all of
> > > the bundles that use them than to require a central service definition
> > > bundle (see
http://161.58.208.149/devzone/members/faq/index.php#sharing
> > > under the tech faqs on the OSGi DevZone). At least, that's true in
highly
> > > dynamic environments where service definitions may come and go. This
may
> > > not be true of general RCP usecases.
> > >
> > > As far as explicitly placing bundle dependencies in the bundles,
keeping
> > > dependency info external to the bundles would allow for more
extensible
> > > deployment scenarios. For instance, my project (AppPlugin) uses
different
> > > implementations of a certain service for external and internal
> > > deployments. So now I have to create two AppPlugin projects to
account
> > > for the different bundle dependencies. If this information were kept
> > > external to the AppPlugin bundle, say in a Deployment project, I could
> > > create keep a single AppPlugin project (since it's a lot of code) and
> > > create two Deployment projects instead.
> > >
> > > -Stephen
> > >
> > > Jeff McAffer wrote:
> > >
> > > > These are great questions. See my comments...
> > >
> > > > "Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
> > > > news:bu4r67$7lq$1@eclipse.org...
> > > > > The MANIFEST.MF generated by PDE includes "Require-Bundle" and
> > > > > "Provides-Packages" headers in place of the OSGi
> > "Import/Export-Package"
> > > > > and "Import/Export-Service" headers. I understand the need to add
> > extra
> > > > > headers to augment the functionality provided by OSGi, but why did
you
> > > > > choose to remove the OSGi headers. It looks like they can
co-exist.
> > > > > The effect of excluding the OSGi headers is:
> > >
> > > > They can and do co-exist. The manifest generator happens to
generate
> > > > manifests using Require/Provide since those semantics most closely
match
> > > > what we see in Eclipse. There are instances of Import/Export (and
both)
> > in
> > > > some of the manifests in Eclipse (see runtime or
update.configurator).
> > >
> > > > > 1) You cannot use the generated MANIFEST.MF if you want to deploy
to
> > other
> > > > > OSGi implementations.
> > >
> > > > True today but we are working with the OSGi community to add new
> > dependency
> > > > expressions to the spec. OSGi 4.0 may well include support for this
> > style
> > > > of bundle dependencies.
> > >
> > > > > 2) You lose the ability to dynamically swap different
implementations
> > of
> > > > > services that are packaged in different bundles since you are
bound by
> > the
> > > > > actual bundles instead of the service interfaces they export.
> > >
> > > > The standard OSGi Import/Export Package and services mechanism are
very
> > > > useful/powerful. But it turns out that in many of our (and others)
> > > > usecases, you actually don't want to get implementations from others
> > and/or
> > > > use services. For example, product guys are absolutely freaked out
by
> > the
> > > > idea that they could not control the exact implementation
constraints.
> > My
> > > > sense (no validation) is that OSGi's traditional audience (gateway
> > providers
> > > > etc) had much more control over the OSGi installation/configuration
than
> > we
> > > > see with Eclipse scenarios. Thus, specifying a dependency on a
package
> > X
> > > > and relying on a system integrator to only make available reasonable
> > > > implementations of X makes sense. In Eclipse scenarios the system
> > > > integrator is more often than not, the end user. They neither have
the
> > > > knowledge or interest to deal with this level of detail.
> > >
> > > > The other thing to note its that not all Eclipse plugins/bundles
contain
> > > > code. Doc plugins for example supply content to the help system.
How
> > can I
> > > > express a dependency that particular doc be installed?
> > >
> > > > > The
> > > > > workaround is to package the service definitions in a separate
bundle
> > so
> > > > > that client bundles are dependent on the definition bundle rather
than
> > the
> > > > > implemenation bundle(s). However, that can quickly become
cumbersome.
> > In
> > > > > fact, the OSGi FAQs suggest avoiding this approach. Instead, they
> > suggest
> > > > > including the service definition (and resulting dependency graph)
in
> > > > > whatever bundles require.
> > >
> > > > May have gotten you wrong but my understanding of OSGi common
practice
> > is
> > > > that the service APIs are in a bundle by themselves and the
> > implementations
> > > > are in other bundles. If you lump the API and the implementation
> > together
> > > > then the effects of configuration changes (e.g., updating a bundle)
will
> > > > propagate much further causing more of the system to shutdown and
> > restart.
> > >
> > > > >Does Eclipse have a tool for exporting a set of
> > > > > classes and the result dependency graph? If so, one could define
a
> > common
> > > > > base project (not plug-in) and export subsets of it to jars to be
> > included
> > > > > in dependent bundles. This would alleviate the need for
hardcoding of
> > > > > bundle dependencies.
> > >
> > > > I do not know of such a tool.
> > >
> > > > > If mapping bundle dependencies is a requirement,
> > > > > maybe it could be moved to the encompasing feature project so that
the
> > > > > dependencies are kept external to the bundle definitions.
> > >
> > > > Features are not part of the runtime. Of couse, we could make them
be
> > but
> > > > it is unclear how this would help. If the classloaders look at and
> > follow
> > > > the dependencies expressed by the features (as well as the
Import/Export
> > > > dependencies), you get the same net effect.
> > >
> > > > Jeff
> > >
> > >
>
>
|
|
|
| Re: What happened to Export-Package, etc.? [message #34322 is a reply to message #34184] |
Wed, 21 January 2004 19:41 |
Stephen Goldbaum
Messages: 75
Registered: July 2009 |
Member |
|
|
That sounds reasonable. Looking forward to using it :)
Jeff McAffer wrote:
> I agree with all that is being said here. I see it as a producer/consumer
> problem. As the producer of a plugin I want to be able to specify what I
> depend on. In OSGi today I can spec the packages I need but not the
> implementation. The proposal is to extend that and allow me to spec the
> actual bundle (id and version) I require. This allows me to clearly set
> expectations and define tested configurations etc.
> As a plugin consumer I may well have scenarios in which the producers
> assumptions/assertions are invalid. If I am willing to take on the testing
> and support load, I should be free to effectively override the declarations
> that the producer made.
> Our overall direction is to accomodate both of these views. To date we have
> only proposed/implemented the producer's point of view. This has been done
> by extending the notion of Bundle to include explicit interbundle
> dependencies (Require-Bundle).
> In the framework spec currently there is no place for one to define the
> consumer's point of view. Personally I don't think that the framework
> should define another runtime entity for this informaton. Rather, it should
> expose API on PackageAdmin (or some such) where someone with a consumer's
> viewpoint can specify overrides or additional dependencies. This is input
> to the runtime (e.g., package/bundle resolution) but we need not spec how
> this information is managed.
> OSGi RFP44 contains the notion of "bundle suites". While they have not
> really been defined as yet, they appear to be somewhat akin to Eclipse
> features. Note that Eclipse featuers are NOT a runtime entity. They are a
> delivery mechanism and they do not have the ability to specify or override
> interplugin dependencies. It would be interesting to add these abilities to
> features/suites but that does not seem like the end of the story. Features
> are just another level of component and so again suffer from the
> producer/consumer view point problems. So, while it is intresting to spec
> dependencies/overrides in features, there is still a need to have global
> "configuration" level control.
> So rather there creating explicit support for each of these parties at the
> core level of the framework, I would prefer to see a general mechanism which
> simply takes a set of overrides/dependencies and uses them during
> resolution. It would then be up to a configuraiton agent to observe the
> data in the features, suites, config data, then prioritize and apply. We
> are headed that way with our PlatformAdmin service. It is unclear how far
> we will get for 3.0.
> Wow, I had a lot to say!
> Jeff
> , it would be reasonable to add this information. In fact they are defined
> by the install/update component for managing collections of plugins/bundles.
> I personally very much like this characteristic.
> "Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
> news:bu9hvs$mpe$1@eclipse.org...
> > That might be true, but I think the required bundle concept is a good
> > feature and I'd like to use it. It just seems that if the bundle
> > dependencies were described externally, it would facilitate more flexible
> > deployment scenarios. I'm not very familiar with Ecplipse Plugins, but I
> > thought that's what Features were for.
> >
> > Of course, you could achieve the same effect in OSGi by placing the bundle
> > location in the properties of every service registered by that bundle.
> > Dependent bundles could then filter for services based on this value.
> > This would be pretty laborious and better left to the build environment.
> >
> >
> > Sten Ernerot wrote:
> >
> > > Hi
> >
> > > I dont think that "required-bundle" tag is needed during runtime.
> > > If you define Import-Package in your AppPlugin (and Export-Package in
> your
> > > service) it should work.
> >
> > > Cheers
> > > Sten
> >
> >
> > > "Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
> > > news:bu944p$542$1@eclipse.org...
> > > > Hey Jeff,
> > > >
> > > > Thanks for all of the answers.
> > > >
> > > > Concerning including the service APIs in the implementation bundle,
> you
> > > > got me right. It's just easier to include the shared interfaces in
> all of
> > > > the bundles that use them than to require a central service definition
> > > > bundle (see
> http://161.58.208.149/devzone/members/faq/index.php#sharing
> > > > under the tech faqs on the OSGi DevZone). At least, that's true in
> highly
> > > > dynamic environments where service definitions may come and go. This
> may
> > > > not be true of general RCP usecases.
> > > >
> > > > As far as explicitly placing bundle dependencies in the bundles,
> keeping
> > > > dependency info external to the bundles would allow for more
> extensible
> > > > deployment scenarios. For instance, my project (AppPlugin) uses
> different
> > > > implementations of a certain service for external and internal
> > > > deployments. So now I have to create two AppPlugin projects to
> account
> > > > for the different bundle dependencies. If this information were kept
> > > > external to the AppPlugin bundle, say in a Deployment project, I could
> > > > create keep a single AppPlugin project (since it's a lot of code) and
> > > > create two Deployment projects instead.
> > > >
> > > > -Stephen
> > > >
> > > > Jeff McAffer wrote:
> > > >
> > > > > These are great questions. See my comments...
> > > >
> > > > > "Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
> > > > > news:bu4r67$7lq$1@eclipse.org...
> > > > > > The MANIFEST.MF generated by PDE includes "Require-Bundle" and
> > > > > > "Provides-Packages" headers in place of the OSGi
> > > "Import/Export-Package"
> > > > > > and "Import/Export-Service" headers. I understand the need to add
> > > extra
> > > > > > headers to augment the functionality provided by OSGi, but why did
> you
> > > > > > choose to remove the OSGi headers. It looks like they can
> co-exist.
> > > > > > The effect of excluding the OSGi headers is:
> > > >
> > > > > They can and do co-exist. The manifest generator happens to
> generate
> > > > > manifests using Require/Provide since those semantics most closely
> match
> > > > > what we see in Eclipse. There are instances of Import/Export (and
> both)
> > > in
> > > > > some of the manifests in Eclipse (see runtime or
> update.configurator).
> > > >
> > > > > > 1) You cannot use the generated MANIFEST.MF if you want to deploy
> to
> > > other
> > > > > > OSGi implementations.
> > > >
> > > > > True today but we are working with the OSGi community to add new
> > > dependency
> > > > > expressions to the spec. OSGi 4.0 may well include support for this
> > > style
> > > > > of bundle dependencies.
> > > >
> > > > > > 2) You lose the ability to dynamically swap different
> implementations
> > > of
> > > > > > services that are packaged in different bundles since you are
> bound by
> > > the
> > > > > > actual bundles instead of the service interfaces they export.
> > > >
> > > > > The standard OSGi Import/Export Package and services mechanism are
> very
> > > > > useful/powerful. But it turns out that in many of our (and others)
> > > > > usecases, you actually don't want to get implementations from others
> > > and/or
> > > > > use services. For example, product guys are absolutely freaked out
> by
> > > the
> > > > > idea that they could not control the exact implementation
> constraints.
> > > My
> > > > > sense (no validation) is that OSGi's traditional audience (gateway
> > > providers
> > > > > etc) had much more control over the OSGi installation/configuration
> than
> > > we
> > > > > see with Eclipse scenarios. Thus, specifying a dependency on a
> package
> > > X
> > > > > and relying on a system integrator to only make available reasonable
> > > > > implementations of X makes sense. In Eclipse scenarios the system
> > > > > integrator is more often than not, the end user. They neither have
> the
> > > > > knowledge or interest to deal with this level of detail.
> > > >
> > > > > The other thing to note its that not all Eclipse plugins/bundles
> contain
> > > > > code. Doc plugins for example supply content to the help system.
> How
> > > can I
> > > > > express a dependency that particular doc be installed?
> > > >
> > > > > > The
> > > > > > workaround is to package the service definitions in a separate
> bundle
> > > so
> > > > > > that client bundles are dependent on the definition bundle rather
> than
> > > the
> > > > > > implemenation bundle(s). However, that can quickly become
> cumbersome.
> > > In
> > > > > > fact, the OSGi FAQs suggest avoiding this approach. Instead, they
> > > suggest
> > > > > > including the service definition (and resulting dependency graph)
> in
> > > > > > whatever bundles require.
> > > >
> > > > > May have gotten you wrong but my understanding of OSGi common
> practice
> > > is
> > > > > that the service APIs are in a bundle by themselves and the
> > > implementations
> > > > > are in other bundles. If you lump the API and the implementation
> > > together
> > > > > then the effects of configuration changes (e.g., updating a bundle)
> will
> > > > > propagate much further causing more of the system to shutdown and
> > > restart.
> > > >
> > > > > >Does Eclipse have a tool for exporting a set of
> > > > > > classes and the result dependency graph? If so, one could define
> a
> > > common
> > > > > > base project (not plug-in) and export subsets of it to jars to be
> > > included
> > > > > > in dependent bundles. This would alleviate the need for
> hardcoding of
> > > > > > bundle dependencies.
> > > >
> > > > > I do not know of such a tool.
> > > >
> > > > > > If mapping bundle dependencies is a requirement,
> > > > > > maybe it could be moved to the encompasing feature project so that
> the
> > > > > > dependencies are kept external to the bundle definitions.
> > > >
> > > > > Features are not part of the runtime. Of couse, we could make them
> be
> > > but
> > > > > it is unclear how this would help. If the classloaders look at and
> > > follow
> > > > > the dependencies expressed by the features (as well as the
> Import/Export
> > > > > dependencies), you get the same net effect.
> > > >
> > > > > Jeff
> > > >
> > > >
> >
> >
|
|
| |
| Re: What happened to Export-Package, etc.? [message #34943 is a reply to message #34524] |
Tue, 10 February 2004 14:27 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Stephen,
Service binder is definitely interesting but is still orthogonal to the
explicit interbundle dependencies we propose/have. In short, all of these
are good ideas but do not completely cover each other.
Jeff
"Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
news:busi11$g3j$1@eclipse.org...
> On second thought... If you have a service managing bundle
> dependencies/overrides, then why would you put dependency information in
> the bundle manifest at all? That would be redundent, since this
> PlatformAdmin service (or whatever OSGi comes up with) has to manage all
> of this anyway. Which brings us back to storing this info externally.
> Maybe in this new Bundle Suite descriptor... Or was that what you were
> getting at?
>
> While we're at it, another useful service would be a Service Dependency
> Service that manages service registrations based on the status of other
> services. The authors of Oscar provide something akin to this with their
> ServiceBinder bundle
> (http://gravity.sourceforge.net/servicebinder/download.html). It's very
> useful except the dependencies are limited to design time. Any
> configuration changes require repackaging. Seems like the same solution
> you mention for managing bundle dependencies could apply to this as well
> (with the extra complication of ServiceRegistration management, of
course).
>
>
> -Stephen
>
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 22:57:55 GMT 2024
Powered by FUDForum. Page generated in 0.03689 seconds |
] 
Search
Help
Register
Login
Home
