You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Oberhuber, Martin" <Ma...@windriver.com> on 2008/02/01 14:19:01 UTC
RE: Support for OSGi
Hello Niall / Stuart,
thanks for your answers. It looks like the usage patterns
of OSGi in the Apache and Eclipse communities are just
a bit different: Apache focuses on packages whereas Eclipse
focuses on Bundle granularity for Re-use.
That's why we don't explicitly import all exported packages
at Eclipse -- we're using Require-Bundle instead of
Import-Package throughout our system, mostly due to the way
Eclipse Plugins have been workign in the past. For details,
see also
http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html
What does that mean in practice?
1.) Looks like we Eclipse folk will need to continue writing
our own OSGi Manifests for some time since the
"Require-Bundle" vs. "Import-Package" patterns do not
mix too well.
2.) Whenever somebody converts an auto-generated OSGi Manifest
into a manually maintained one, it's worth thinking about
a) What packages are really API and thus worth being
exported, versus what packages are considered internal
hidden implementation;
b) What packages are expected to be potentially split
across multiple bundles, or would always reside inside
the same bundle.
Or am I missing something?
Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: mcculls@gmail.com [mailto:mcculls@gmail.com] On Behalf
> Of Stuart McCulloch
> Sent: Donnerstag, 31. Jänner 2008 16:53
> To: dev@felix.apache.org
> Cc: Jakarta Commons Developers List; Orbit Developer discussion
> Subject: Re: Support for OSGi
>
> On 31/01/2008, Oberhuber, Martin
> <Ma...@windriver.com> wrote:
> >
> > Hello Niall,
> >
> > it would be interesting for Eclipse consumers as
> > well to get Apache bundles with Meta-info already
> > applied.
> >
> > Currently, the Meta-info is mostly added manually
> > as part of the Eclipse Orbit project.
> >
> > I have had a brief look at your auto-generated
> > MANIFEST for commons net, and found a few issues:
> >
> >
> http://people.apache.org/~niallp/commons-osgi/commons-net-1.5.
> 0-SNAPSHOT
> > -MANIFEST.MF
> >
> > 1. Import-Package: examples;version="1.5.0.SNAPSHOT"
> > this is just wrong. The commons net deliverable
> > jar should not import examples.
>
>
> I assume there's an examples package somewhere (or something
> pulls in the
> examples package)
> You can explicitly ask Bnd to remove/ignore this import by
> using !examples
> in the Import-Package
> if you know that you won't actually need it during runtime (ie. it's
> dead/unused code)
>
> eg: <Import-Package>!examples,*</Import-Package>
>
> 2. Import-Package: org.apache.commons.net.smtp
> > this is also wrong though less destructive.
> > commons.net.smtp is really exported and not imported.
>
>
> Actually this is correct - it's good practice to import your
> exports as it
> ensures a consistent class
> space and avoids problems when upgrading bundles. Otherwise
> you *will* run
> into casting issues.
>
> 3. Export-Package:
> >
> org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,o
> rg.apache.
> > commons.net"
> > It's useless to add a "uses" directive for
> > packages that are in the same bundle. At
> > Eclipse-Orbit, we've found problems with "uses"
> > and decided to no longer use it.
>
>
> As Peter says, he's recently updated Bnd to give users more
> control over
> "uses" and improved
> the default generation. BTW, there is a good reason for the
> "uses" clause as
> explained by Glyn:
>
>
> http://underlap.blogspot.com/2007/10/osgi-type-safety-and-uses
> -directive.html
>
> I haven't seen any problem with "uses" on Felix, but I guess
> Equinox could
> always add an option
> to ignore it - as there are likely to be other bundles out
> there that have
> "uses" in their manifest.
>
> I guess that these should perhaps really be bug
> > reports against the Bnd utility which autogenerated
> > the Manifest; Tool: Bnd-0.0.227.
>
>
> The elimination of "uses" is really a new feature, and the imports of
> exports is not a bug - the
> only bug (as such) is the appearance of the "examples"
> package, but I'd need
> to see the final
> jar to understand why Bnd detected it (ie. it may be a
> justified import
> based on the content)
>
> But for me, it also shows that in the current stage
> > it looks like the OSGi manifest still needs to be
> > written by hand and not auto-generated.
>
>
> From experience I'd argue it's the other way round - OSGi
> manifests should
> be auto-generated.
> But, as with any tool, you should verify it yourself and add
> any customized
> attributes and minor
> adjustments.
>
> Otherwise you'll have to manually keep the manifest in step
> with your code,
> and it's amazingly
> easy to miss imports when they're buried inside the code,
> which is why such
> tools are needed.
>
> The other benefit of auto-generation is you can do it
> dynamically - for
> example, at OPS4J we
> have a deployment tool that lets you load third-party jars which
> automatically get turned into
> OSGi bundles. This really helps with rapid prototyping (great
> if you have a
> legacy jar, but don't
> know the code well enough to craft an OSGi manifest yourself)
>
> Anyways, if there is a plan to make a downloadable
> > release of any commons packages with OSGi info
> > added, I'd like to know.
> >
> > Thanks,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> >
> >
> > > -----Original Message-----
> > > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > > Sent: Tuesday, January 29, 2008 11:30 PM
> > > To: Commons Developers List
> > > Cc: dev@felix.apache.org
> > > Subject: Re: Support for OSGi
> > >
> > > I have created a JIRA ticket for the changes to the
> commons-parent pom
> > > to add the bundle plugin:
> > > https://issues.apache.org/jira/browse/COMMONSSITE-23
> > >
> > > I have also tested out the plugin by generating the
> jars/manifest for
> > > all but three components:
> > > http://people.apache.org/~niallp/commons-osgi/
> > >
> > > I'll leave the ticket open for a few days - but unless there are
> > > objections/issues raised I plan to apply the changes to
> > > commons-parent.
> > >
> > > Niall
> > >
> > > On Dec 19, 2007 2:38 PM, Carsten Ziegeler
> > > <cz...@apache.org> wrote:
> > > > Hi,
> > > >
> > > > the products of commons are highly used throughout many
> projects.
> > > >
> > > > It would be great, if the projects here at Apche
> Commons could help
> > > > those projects that are using OSGi.
> > > >
> > > > OSGi is based around the concept of a bundle - a bundle is
> > > a jar file
> > > > with additional meta data like the packages it exports
> and a list of
> > > > external packages it is using (please forgive me if I'm
> > > simplifying here
> > > > too much).
> > > >
> > > > As many projects are using artifacts from Apache Commons,
> > > they need the
> > > > specific jars as bundles. This is most often done by
> > > creating so called
> > > > wrapper bundles: these are jars that have the same
> contents as the
> > > > original library with the addition of the required meta data.
> > > > You can find several examples here:
> > > >
> > > > http://svn.apache.org/repos/asf/felix/trunk/commons/
> > > >
> > > > Now, it would be great, if the projects here at Apache
> Commons would
> > > > already provide artifacs that can be directly used in an
> > > OSGi environment.
> > > >
> > > > All that has to be done is adding some entries to the
> > > manifest. This is
> > > > usually a list of imported packages, a list of exported
> packages, a
> > > > symbolic name for the bundle and a version. (There are
> some more but
> > > > these are the most important ones).
> > > >
> > > > Adding these entries can be done by hand (not recommended)
> > > or with tools
> > > > automatically. For example the Apache Felix maven
> > > bundleplugin requires
> > > > just some lines of configuration and that's it.
> > > >
> > > > It would be great if some of the projects here could add
> > > these meta data
> > > > as part of their next release. This will make the life of
> > > all projects
> > > > using OSGi much much easier.
> > > >
> > > > So if you're interested in helping us, just let us
> know. We would be
> > > > happy to make the required changes to the poms or whatever
> > > needs to be
> > > > done. I cc'ed the Felix dev list as some Felix developers
> > > might not be
> > > > subscribed to the commons dev list, so please keep them
> > > cross posted.
> > > >
> > > > Thanks
> > > > Carsten
> > > > --
> > > > Carsten Ziegeler
> > > > cziegeler@apache.org
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> Cheers, Stuart
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Support for OSGi
Posted by Stuart McCulloch <st...@jayway.net>.
On 01/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
>
> On Feb 1, 2008 1:19 PM, Oberhuber, Martin
> <Ma...@windriver.com> wrote:
> > Hello Niall / Stuart,
> >
> > thanks for your answers. It looks like the usage patterns
> > of OSGi in the Apache and Eclipse communities are just
> > a bit different: Apache focuses on packages whereas Eclipse
> > focuses on Bundle granularity for Re-use.
> >
> > That's why we don't explicitly import all exported packages
> > at Eclipse -- we're using Require-Bundle instead of
> > Import-Package throughout our system, mostly due to the way
> > Eclipse Plugins have been workign in the past. For details,
> > see also
> >
> > http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html
> >
> > What does that mean in practice?
> >
> > 1.) Looks like we Eclipse folk will need to continue writing
> > our own OSGi Manifests for some time since the
> > "Require-Bundle" vs. "Import-Package" patterns do not
> > mix too well.
True - of course, if you have several bundles exporting the same package(s)
but not importing them, then while this means Require-Bundle will be more
predictable, it also means that you're more likely to see class cast
problems
when you mix 'traditional' OSGi bundles with Eclipse plug-ins.
BTW, here's an example why Require-Bundle is so inflexible, from Spring-DM:
<story>
Spring-DM uses the commons-logging API, but not the implementation
because it doesn't work well with OSGi classloading (see the Spring-DM
FAQ for more detail). People usually use Pax-Logging or other adapters,
which is possible because Spring-DM gets the API using Import-Package.
Recently a developer using Spring-DM and Eclipse RCP reported a logging
problem (he saw the usual exception when using the commons-logging
implementation) so we suggested he switched to another adapter.
Unfortunately he was also using the commons-discovery bundle (I think
from Orbit?) which has a Require-Bundle for commons-logging. This hard
dependency meant he couldn't substitute another logging bundle, while
he could have done if Import-Package was used.
In the end he re-bundled commons-discovery to use Import-Package
which fixed the problem, and he now has Spring-DM working with RCP.
</story>
Given that commons bundles will be used by the wider community then IMHO
they should use the Import-Package approach - hopefully plug-in developers
will start using it over Require-Bundle (at least for commons packages).
It would have been good to meet everyone's needs but from the link you
> posted and what Peter and Stuart have said in this thread then that
> doesn't seem possible and from my limited perspective it seems clear
> that we (in Commons) should follow whats considerd good OSGi practice
> rather than those of eclipse.
>
> Niall
>
> > 2.) Whenever somebody converts an auto-generated OSGi Manifest
> > into a manually maintained one, it's worth thinking about
> > a) What packages are really API and thus worth being
> > exported, versus what packages are considered internal
> > hidden implementation;
Actually with Bnd, you tell it which packages to export and which to keep
private - it's just that most commons projects will start by exporting all
packages, then over time mark some as private. Some commons jars
may also need Bundle-Activators to manage life-cycle issues, such as
background threads, etc. under OSGi.
You can read more about Bnd here: http://aqute.biz/Code/Bnd
> b) What packages are expected to be potentially split
> > across multiple bundles, or would always reside inside
> > the same bundle.
Again, while Bnd allows split-packages (with a warning) they are usually
not recommended from a 'traditional' OSGi perspective as they quickly
turn into a management nightmare.
FYI, SLF4J used to use split packages, but they refactored their jars to
avoid them, and it solved a lot of issues.
>
> > Or am I missing something?
> >
> > Thanks,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
>
> --
Cheers, Stuart
Re: Support for OSGi
Posted by Stuart McCulloch <st...@jayway.net>.
On 01/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
>
> On Feb 1, 2008 1:19 PM, Oberhuber, Martin
> <Ma...@windriver.com> wrote:
> > Hello Niall / Stuart,
> >
> > thanks for your answers. It looks like the usage patterns
> > of OSGi in the Apache and Eclipse communities are just
> > a bit different: Apache focuses on packages whereas Eclipse
> > focuses on Bundle granularity for Re-use.
> >
> > That's why we don't explicitly import all exported packages
> > at Eclipse -- we're using Require-Bundle instead of
> > Import-Package throughout our system, mostly due to the way
> > Eclipse Plugins have been workign in the past. For details,
> > see also
> >
> > http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html
> >
> > What does that mean in practice?
> >
> > 1.) Looks like we Eclipse folk will need to continue writing
> > our own OSGi Manifests for some time since the
> > "Require-Bundle" vs. "Import-Package" patterns do not
> > mix too well.
True - of course, if you have several bundles exporting the same package(s)
but not importing them, then while this means Require-Bundle will be more
predictable, it also means that you're more likely to see class cast
problems
when you mix 'traditional' OSGi bundles with Eclipse plug-ins.
BTW, here's an example why Require-Bundle is so inflexible, from Spring-DM:
<story>
Spring-DM uses the commons-logging API, but not the implementation
because it doesn't work well with OSGi classloading (see the Spring-DM
FAQ for more detail). People usually use Pax-Logging or other adapters,
which is possible because Spring-DM gets the API using Import-Package.
Recently a developer using Spring-DM and Eclipse RCP reported a logging
problem (he saw the usual exception when using the commons-logging
implementation) so we suggested he switched to another adapter.
Unfortunately he was also using the commons-discovery bundle (I think
from Orbit?) which has a Require-Bundle for commons-logging. This hard
dependency meant he couldn't substitute another logging bundle, while
he could have done if Import-Package was used.
In the end he re-bundled commons-discovery to use Import-Package
which fixed the problem, and he now has Spring-DM working with RCP.
</story>
Given that commons bundles will be used by the wider community then IMHO
they should use the Import-Package approach - hopefully plug-in developers
will start using it over Require-Bundle (at least for commons packages).
It would have been good to meet everyone's needs but from the link you
> posted and what Peter and Stuart have said in this thread then that
> doesn't seem possible and from my limited perspective it seems clear
> that we (in Commons) should follow whats considerd good OSGi practice
> rather than those of eclipse.
>
> Niall
>
> > 2.) Whenever somebody converts an auto-generated OSGi Manifest
> > into a manually maintained one, it's worth thinking about
> > a) What packages are really API and thus worth being
> > exported, versus what packages are considered internal
> > hidden implementation;
Actually with Bnd, you tell it which packages to export and which to keep
private - it's just that most commons projects will start by exporting all
packages, then over time mark some as private. Some commons jars
may also need Bundle-Activators to manage life-cycle issues, such as
background threads, etc. under OSGi.
You can read more about Bnd here: http://aqute.biz/Code/Bnd
> b) What packages are expected to be potentially split
> > across multiple bundles, or would always reside inside
> > the same bundle.
Again, while Bnd allows split-packages (with a warning) they are usually
not recommended from a 'traditional' OSGi perspective as they quickly
turn into a management nightmare.
FYI, SLF4J used to use split packages, but they refactored their jars to
avoid them, and it solved a lot of issues.
>
> > Or am I missing something?
> >
> > Thanks,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
>
> --
Cheers, Stuart
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 1, 2008 1:19 PM, Oberhuber, Martin
<Ma...@windriver.com> wrote:
> Hello Niall / Stuart,
>
> thanks for your answers. It looks like the usage patterns
> of OSGi in the Apache and Eclipse communities are just
> a bit different: Apache focuses on packages whereas Eclipse
> focuses on Bundle granularity for Re-use.
>
> That's why we don't explicitly import all exported packages
> at Eclipse -- we're using Require-Bundle instead of
> Import-Package throughout our system, mostly due to the way
> Eclipse Plugins have been workign in the past. For details,
> see also
>
> http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html
>
> What does that mean in practice?
>
> 1.) Looks like we Eclipse folk will need to continue writing
> our own OSGi Manifests for some time since the
> "Require-Bundle" vs. "Import-Package" patterns do not
> mix too well.
It would have been good to meet everyone's needs but from the link you
posted and what Peter and Stuart have said in this thread then that
doesn't seem possible and from my limited perspective it seems clear
that we (in Commons) should follow whats considerd good OSGi practice
rather than those of eclipse.
Niall
> 2.) Whenever somebody converts an auto-generated OSGi Manifest
> into a manually maintained one, it's worth thinking about
> a) What packages are really API and thus worth being
> exported, versus what packages are considered internal
> hidden implementation;
> b) What packages are expected to be potentially split
> across multiple bundles, or would always reside inside
> the same bundle.
>
> Or am I missing something?
>
> Thanks,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>
>
>
> > -----Original Message-----
> > From: mcculls@gmail.com [mailto:mcculls@gmail.com] On Behalf
> > Of Stuart McCulloch
> > Sent: Donnerstag, 31. Jänner 2008 16:53
> > To: dev@felix.apache.org
> > Cc: Jakarta Commons Developers List; Orbit Developer discussion
> > Subject: Re: Support for OSGi
> >
>
> > On 31/01/2008, Oberhuber, Martin
> > <Ma...@windriver.com> wrote:
> > >
> > > Hello Niall,
> > >
> > > it would be interesting for Eclipse consumers as
> > > well to get Apache bundles with Meta-info already
> > > applied.
> > >
> > > Currently, the Meta-info is mostly added manually
> > > as part of the Eclipse Orbit project.
> > >
> > > I have had a brief look at your auto-generated
> > > MANIFEST for commons net, and found a few issues:
> > >
> > >
> > http://people.apache.org/~niallp/commons-osgi/commons-net-1.5.
> > 0-SNAPSHOT
> > > -MANIFEST.MF
> > >
> > > 1. Import-Package: examples;version="1.5.0.SNAPSHOT"
> > > this is just wrong. The commons net deliverable
> > > jar should not import examples.
> >
> >
> > I assume there's an examples package somewhere (or something
> > pulls in the
> > examples package)
> > You can explicitly ask Bnd to remove/ignore this import by
> > using !examples
> > in the Import-Package
> > if you know that you won't actually need it during runtime (ie. it's
> > dead/unused code)
> >
> > eg: <Import-Package>!examples,*</Import-Package>
> >
> > 2. Import-Package: org.apache.commons.net.smtp
> > > this is also wrong though less destructive.
> > > commons.net.smtp is really exported and not imported.
> >
> >
> > Actually this is correct - it's good practice to import your
> > exports as it
> > ensures a consistent class
> > space and avoids problems when upgrading bundles. Otherwise
> > you *will* run
> > into casting issues.
> >
> > 3. Export-Package:
> > >
> > org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,o
> > rg.apache.
> > > commons.net"
> > > It's useless to add a "uses" directive for
> > > packages that are in the same bundle. At
> > > Eclipse-Orbit, we've found problems with "uses"
> > > and decided to no longer use it.
> >
> >
> > As Peter says, he's recently updated Bnd to give users more
> > control over
> > "uses" and improved
> > the default generation. BTW, there is a good reason for the
> > "uses" clause as
> > explained by Glyn:
> >
> >
> > http://underlap.blogspot.com/2007/10/osgi-type-safety-and-uses
> > -directive.html
> >
> > I haven't seen any problem with "uses" on Felix, but I guess
> > Equinox could
> > always add an option
> > to ignore it - as there are likely to be other bundles out
> > there that have
> > "uses" in their manifest.
> >
> > I guess that these should perhaps really be bug
> > > reports against the Bnd utility which autogenerated
> > > the Manifest; Tool: Bnd-0.0.227.
> >
> >
> > The elimination of "uses" is really a new feature, and the imports of
> > exports is not a bug - the
> > only bug (as such) is the appearance of the "examples"
> > package, but I'd need
> > to see the final
> > jar to understand why Bnd detected it (ie. it may be a
> > justified import
> > based on the content)
> >
> > But for me, it also shows that in the current stage
> > > it looks like the OSGi manifest still needs to be
> > > written by hand and not auto-generated.
> >
> >
> > From experience I'd argue it's the other way round - OSGi
> > manifests should
> > be auto-generated.
> > But, as with any tool, you should verify it yourself and add
> > any customized
> > attributes and minor
> > adjustments.
> >
> > Otherwise you'll have to manually keep the manifest in step
> > with your code,
> > and it's amazingly
> > easy to miss imports when they're buried inside the code,
> > which is why such
> > tools are needed.
> >
> > The other benefit of auto-generation is you can do it
> > dynamically - for
> > example, at OPS4J we
> > have a deployment tool that lets you load third-party jars which
> > automatically get turned into
> > OSGi bundles. This really helps with rapid prototyping (great
> > if you have a
> > legacy jar, but don't
> > know the code well enough to craft an OSGi manifest yourself)
> >
> > Anyways, if there is a plan to make a downloadable
> > > release of any commons packages with OSGi info
> > > added, I'd like to know.
> > >
> > > Thanks,
> > > --
> > > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > > Target Management Project Lead, DSDP PMC Member
> > > http://www.eclipse.org/dsdp/tm
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > > > Sent: Tuesday, January 29, 2008 11:30 PM
> > > > To: Commons Developers List
> > > > Cc: dev@felix.apache.org
> > > > Subject: Re: Support for OSGi
> > > >
> > > > I have created a JIRA ticket for the changes to the
> > commons-parent pom
> > > > to add the bundle plugin:
> > > > https://issues.apache.org/jira/browse/COMMONSSITE-23
> > > >
> > > > I have also tested out the plugin by generating the
> > jars/manifest for
> > > > all but three components:
> > > > http://people.apache.org/~niallp/commons-osgi/
> > > >
> > > > I'll leave the ticket open for a few days - but unless there are
> > > > objections/issues raised I plan to apply the changes to
> > > > commons-parent.
> > > >
> > > > Niall
> > > >
> > > > On Dec 19, 2007 2:38 PM, Carsten Ziegeler
> > > > <cz...@apache.org> wrote:
> > > > > Hi,
> > > > >
> > > > > the products of commons are highly used throughout many
> > projects.
> > > > >
> > > > > It would be great, if the projects here at Apche
> > Commons could help
> > > > > those projects that are using OSGi.
> > > > >
> > > > > OSGi is based around the concept of a bundle - a bundle is
> > > > a jar file
> > > > > with additional meta data like the packages it exports
> > and a list of
> > > > > external packages it is using (please forgive me if I'm
> > > > simplifying here
> > > > > too much).
> > > > >
> > > > > As many projects are using artifacts from Apache Commons,
> > > > they need the
> > > > > specific jars as bundles. This is most often done by
> > > > creating so called
> > > > > wrapper bundles: these are jars that have the same
> > contents as the
> > > > > original library with the addition of the required meta data.
> > > > > You can find several examples here:
> > > > >
> > > > > http://svn.apache.org/repos/asf/felix/trunk/commons/
> > > > >
> > > > > Now, it would be great, if the projects here at Apache
> > Commons would
> > > > > already provide artifacs that can be directly used in an
> > > > OSGi environment.
> > > > >
> > > > > All that has to be done is adding some entries to the
> > > > manifest. This is
> > > > > usually a list of imported packages, a list of exported
> > packages, a
> > > > > symbolic name for the bundle and a version. (There are
> > some more but
> > > > > these are the most important ones).
> > > > >
> > > > > Adding these entries can be done by hand (not recommended)
> > > > or with tools
> > > > > automatically. For example the Apache Felix maven
> > > > bundleplugin requires
> > > > > just some lines of configuration and that's it.
> > > > >
> > > > > It would be great if some of the projects here could add
> > > > these meta data
> > > > > as part of their next release. This will make the life of
> > > > all projects
> > > > > using OSGi much much easier.
> > > > >
> > > > > So if you're interested in helping us, just let us
> > know. We would be
> > > > > happy to make the required changes to the poms or whatever
> > > > needs to be
> > > > > done. I cc'ed the Felix dev list as some Felix developers
> > > > might not be
> > > > > subscribed to the commons dev list, so please keep them
> > > > cross posted.
> > > > >
> > > > > Thanks
> > > > > Carsten
> > > > > --
> > > > > Carsten Ziegeler
> > > > > cziegeler@apache.org
> > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cheers, Stuart
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 1, 2008 1:19 PM, Oberhuber, Martin
<Ma...@windriver.com> wrote:
> Hello Niall / Stuart,
>
> thanks for your answers. It looks like the usage patterns
> of OSGi in the Apache and Eclipse communities are just
> a bit different: Apache focuses on packages whereas Eclipse
> focuses on Bundle granularity for Re-use.
>
> That's why we don't explicitly import all exported packages
> at Eclipse -- we're using Require-Bundle instead of
> Import-Package throughout our system, mostly due to the way
> Eclipse Plugins have been workign in the past. For details,
> see also
>
> http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html
>
> What does that mean in practice?
>
> 1.) Looks like we Eclipse folk will need to continue writing
> our own OSGi Manifests for some time since the
> "Require-Bundle" vs. "Import-Package" patterns do not
> mix too well.
It would have been good to meet everyone's needs but from the link you
posted and what Peter and Stuart have said in this thread then that
doesn't seem possible and from my limited perspective it seems clear
that we (in Commons) should follow whats considerd good OSGi practice
rather than those of eclipse.
Niall
> 2.) Whenever somebody converts an auto-generated OSGi Manifest
> into a manually maintained one, it's worth thinking about
> a) What packages are really API and thus worth being
> exported, versus what packages are considered internal
> hidden implementation;
> b) What packages are expected to be potentially split
> across multiple bundles, or would always reside inside
> the same bundle.
>
> Or am I missing something?
>
> Thanks,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>
>
>
> > -----Original Message-----
> > From: mcculls@gmail.com [mailto:mcculls@gmail.com] On Behalf
> > Of Stuart McCulloch
> > Sent: Donnerstag, 31. Jänner 2008 16:53
> > To: dev@felix.apache.org
> > Cc: Jakarta Commons Developers List; Orbit Developer discussion
> > Subject: Re: Support for OSGi
> >
>
> > On 31/01/2008, Oberhuber, Martin
> > <Ma...@windriver.com> wrote:
> > >
> > > Hello Niall,
> > >
> > > it would be interesting for Eclipse consumers as
> > > well to get Apache bundles with Meta-info already
> > > applied.
> > >
> > > Currently, the Meta-info is mostly added manually
> > > as part of the Eclipse Orbit project.
> > >
> > > I have had a brief look at your auto-generated
> > > MANIFEST for commons net, and found a few issues:
> > >
> > >
> > http://people.apache.org/~niallp/commons-osgi/commons-net-1.5.
> > 0-SNAPSHOT
> > > -MANIFEST.MF
> > >
> > > 1. Import-Package: examples;version="1.5.0.SNAPSHOT"
> > > this is just wrong. The commons net deliverable
> > > jar should not import examples.
> >
> >
> > I assume there's an examples package somewhere (or something
> > pulls in the
> > examples package)
> > You can explicitly ask Bnd to remove/ignore this import by
> > using !examples
> > in the Import-Package
> > if you know that you won't actually need it during runtime (ie. it's
> > dead/unused code)
> >
> > eg: <Import-Package>!examples,*</Import-Package>
> >
> > 2. Import-Package: org.apache.commons.net.smtp
> > > this is also wrong though less destructive.
> > > commons.net.smtp is really exported and not imported.
> >
> >
> > Actually this is correct - it's good practice to import your
> > exports as it
> > ensures a consistent class
> > space and avoids problems when upgrading bundles. Otherwise
> > you *will* run
> > into casting issues.
> >
> > 3. Export-Package:
> > >
> > org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,o
> > rg.apache.
> > > commons.net"
> > > It's useless to add a "uses" directive for
> > > packages that are in the same bundle. At
> > > Eclipse-Orbit, we've found problems with "uses"
> > > and decided to no longer use it.
> >
> >
> > As Peter says, he's recently updated Bnd to give users more
> > control over
> > "uses" and improved
> > the default generation. BTW, there is a good reason for the
> > "uses" clause as
> > explained by Glyn:
> >
> >
> > http://underlap.blogspot.com/2007/10/osgi-type-safety-and-uses
> > -directive.html
> >
> > I haven't seen any problem with "uses" on Felix, but I guess
> > Equinox could
> > always add an option
> > to ignore it - as there are likely to be other bundles out
> > there that have
> > "uses" in their manifest.
> >
> > I guess that these should perhaps really be bug
> > > reports against the Bnd utility which autogenerated
> > > the Manifest; Tool: Bnd-0.0.227.
> >
> >
> > The elimination of "uses" is really a new feature, and the imports of
> > exports is not a bug - the
> > only bug (as such) is the appearance of the "examples"
> > package, but I'd need
> > to see the final
> > jar to understand why Bnd detected it (ie. it may be a
> > justified import
> > based on the content)
> >
> > But for me, it also shows that in the current stage
> > > it looks like the OSGi manifest still needs to be
> > > written by hand and not auto-generated.
> >
> >
> > From experience I'd argue it's the other way round - OSGi
> > manifests should
> > be auto-generated.
> > But, as with any tool, you should verify it yourself and add
> > any customized
> > attributes and minor
> > adjustments.
> >
> > Otherwise you'll have to manually keep the manifest in step
> > with your code,
> > and it's amazingly
> > easy to miss imports when they're buried inside the code,
> > which is why such
> > tools are needed.
> >
> > The other benefit of auto-generation is you can do it
> > dynamically - for
> > example, at OPS4J we
> > have a deployment tool that lets you load third-party jars which
> > automatically get turned into
> > OSGi bundles. This really helps with rapid prototyping (great
> > if you have a
> > legacy jar, but don't
> > know the code well enough to craft an OSGi manifest yourself)
> >
> > Anyways, if there is a plan to make a downloadable
> > > release of any commons packages with OSGi info
> > > added, I'd like to know.
> > >
> > > Thanks,
> > > --
> > > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > > Target Management Project Lead, DSDP PMC Member
> > > http://www.eclipse.org/dsdp/tm
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > > > Sent: Tuesday, January 29, 2008 11:30 PM
> > > > To: Commons Developers List
> > > > Cc: dev@felix.apache.org
> > > > Subject: Re: Support for OSGi
> > > >
> > > > I have created a JIRA ticket for the changes to the
> > commons-parent pom
> > > > to add the bundle plugin:
> > > > https://issues.apache.org/jira/browse/COMMONSSITE-23
> > > >
> > > > I have also tested out the plugin by generating the
> > jars/manifest for
> > > > all but three components:
> > > > http://people.apache.org/~niallp/commons-osgi/
> > > >
> > > > I'll leave the ticket open for a few days - but unless there are
> > > > objections/issues raised I plan to apply the changes to
> > > > commons-parent.
> > > >
> > > > Niall
> > > >
> > > > On Dec 19, 2007 2:38 PM, Carsten Ziegeler
> > > > <cz...@apache.org> wrote:
> > > > > Hi,
> > > > >
> > > > > the products of commons are highly used throughout many
> > projects.
> > > > >
> > > > > It would be great, if the projects here at Apche
> > Commons could help
> > > > > those projects that are using OSGi.
> > > > >
> > > > > OSGi is based around the concept of a bundle - a bundle is
> > > > a jar file
> > > > > with additional meta data like the packages it exports
> > and a list of
> > > > > external packages it is using (please forgive me if I'm
> > > > simplifying here
> > > > > too much).
> > > > >
> > > > > As many projects are using artifacts from Apache Commons,
> > > > they need the
> > > > > specific jars as bundles. This is most often done by
> > > > creating so called
> > > > > wrapper bundles: these are jars that have the same
> > contents as the
> > > > > original library with the addition of the required meta data.
> > > > > You can find several examples here:
> > > > >
> > > > > http://svn.apache.org/repos/asf/felix/trunk/commons/
> > > > >
> > > > > Now, it would be great, if the projects here at Apache
> > Commons would
> > > > > already provide artifacs that can be directly used in an
> > > > OSGi environment.
> > > > >
> > > > > All that has to be done is adding some entries to the
> > > > manifest. This is
> > > > > usually a list of imported packages, a list of exported
> > packages, a
> > > > > symbolic name for the bundle and a version. (There are
> > some more but
> > > > > these are the most important ones).
> > > > >
> > > > > Adding these entries can be done by hand (not recommended)
> > > > or with tools
> > > > > automatically. For example the Apache Felix maven
> > > > bundleplugin requires
> > > > > just some lines of configuration and that's it.
> > > > >
> > > > > It would be great if some of the projects here could add
> > > > these meta data
> > > > > as part of their next release. This will make the life of
> > > > all projects
> > > > > using OSGi much much easier.
> > > > >
> > > > > So if you're interested in helping us, just let us
> > know. We would be
> > > > > happy to make the required changes to the poms or whatever
> > > > needs to be
> > > > > done. I cc'ed the Felix dev list as some Felix developers
> > > > might not be
> > > > > subscribed to the commons dev list, so please keep them
> > > > cross posted.
> > > > >
> > > > > Thanks
> > > > > Carsten
> > > > > --
> > > > > Carsten Ziegeler
> > > > > cziegeler@apache.org
> > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cheers, Stuart
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org