You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Carsten Ziegeler <cz...@apache.org> on 2007/12/19 15:38:03 UTC
Support for OSGi
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
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 28, 2007 12:35 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> in the meantime Stuart fixed the problem with the maven bundleplugin, so
> I think we can give it a test drive :)
>
> Attached is a patch for the parent pom of commons and one to demonstrate
> how to add support for OSGi to commons-lang.
>
> The changes to the parent pom are minimal: it just adds the maven
> bundleplugin from the Apache Felix project. We currently need to use a
> snapshot version, but a release is comming soon.
> Besides adding the plugin, the patch also configures the bundle symbolic
> name for all modules. The symbolic name is the unique identifier which
> should follow java package naming. The best value is to use something
> like "org.apache.commons.{artifactId}" where artifact id is commons-lang
> or commons-collections etc.
>
> The patch to commons lang is also very simple. It changes the parent pom
> to the current snapshot (which includes the changes from above) and sets
> the packaging to bundle - this ensures that the bundleplugin runs and
> creates the resulting jar file. So the bundleplugin replaces the maven
> jar plugin. If you leave the packaging as "jar" the bundleplugin will
> not run.
> The last part of the patch adds the configuration to the bundleplugin.
> The export "*" exports all packages definied in this module for other
> bundles, so all classes are public. All packages are marked with the
> current version which allows to run different versions in parallel.
> The imports are not specified as they are calculated automatically by
> the bundleplugin.
>
> And that's it :)
>
> The changes to the other projects should be similar.
I tried using the bundle plugin (I checked out and built the latest
from svn) with Commons Validator and it produced the following
MANIFEST.MF:
http://people.apache.org/~niallp/commons-osgi/commons-validator-MANIFEST.MF
It seems to have picked up some Manifest entries from BeanUtils - for example:
Extension-Name: org.apache.commons.beanutils
Implementation-Version: 1.6
Specification-Title: Jakarta Commons Beanutils
Implementation-Title: org.apache.commons.beanutils
Niall
(N.B. The BeanUtils 1.7.0 jar has version incorectly specifying 1.6 in
its manifest.
> Carsten
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
> Index: /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml
> ===================================================================
> --- /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml (revision 605909)
> +++ /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml (working copy)
> @@ -159,6 +159,12 @@
> <artifactId>maven-release-plugin</artifactId>
> <version>2.0-beta-7</version>
> </plugin>
> + <plugin>
> + <groupId>org.apache.felix</groupId>
> + <artifactId>maven-bundle-plugin</artifactId>
> + <version>1.1.0-SNAPSHOT</version>
> + <inherited>true</inherited>
> + </plugin>
> </plugins>
> </pluginManagement>
> <plugins>
> @@ -194,6 +200,15 @@
> <jdkLevel>${maven.compile.source}</jdkLevel>
> </configuration>
> </plugin>
> + <plugin>
> + <groupId>org.apache.felix</groupId>
> + <artifactId>maven-bundle-plugin</artifactId>
> + <configuration>
> + <instructions>
> + <Bundle-SymbolicName>org.apache.commons.${pom.artifactId}</Bundle-SymbolicName>
> + </instructions>
> + </configuration>
> + </plugin>
> </plugins>
> </build>
>
>
> Index: /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml
> ===================================================================
> --- /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml (revision 605909)
> +++ /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml (working copy)
> @@ -22,13 +22,14 @@
> <parent>
> <groupId>org.apache.commons</groupId>
> <artifactId>commons-parent</artifactId>
> - <version>5</version>
> + <version>6-SNAPSHOT</version>
> </parent>
> <modelVersion>4.0.0</modelVersion>
> <groupId>commons-lang</groupId>
> <artifactId>commons-lang</artifactId>
> <version>2.4-SNAPSHOT</version>
> <name>Commons Lang</name>
> + <packaging>bundle</packaging>
>
> <inceptionYear>2001</inceptionYear>
> <description>
> @@ -401,6 +402,16 @@
> <tarLongFileMode>gnu</tarLongFileMode>
> </configuration>
> </plugin>
> + <plugin>
> + <groupId>org.apache.felix</groupId>
> + <artifactId>maven-bundle-plugin</artifactId>
> + <extensions>true</extensions>
> + <configuration>
> + <instructions>
> + <Export-Package>*;version=${pom.version}</Export-Package>
> + </instructions>
> + </configuration>
> + </plugin>
> </plugins>
> </build>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Support for OSGi
Posted by sebb <se...@gmail.com>.
On 22/01/2008, Jörg Schaible <Jo...@elsag-solutions.com> wrote:
> Mark Proctor wrote:
> > Torsten Curdt wrote:
> >>
> >> On 21.01.2008, at 10:08, Tom Schindl wrote:
> >>
> >>> Hi Torsten,
> >>>
> >>> I understand this but we are seeing many J2EE-Servers adopting OSGi
> >>> and many applications (I admit most of them in Eclipse-world) also.
> >>> It seems strange to me in those envs to use this "artificial"
> >>> package to overcome jar-hell (which is the only reason for the
> >>> java5-package right?) they are not having
> >>> because of OSGi.
> >>
> >> Hm.... not sure why its such a big deal to have e.g.
> >> o.a.commons.lang2 or similar. If you use an IDE that manages imports
> >> you will barely notice anyway.
> > personally I've always wondered why having a version attached to the
> > namespace hasn't taken off more to deal with api breaking
> > releases. if
> > we had org.antlr1 org.antlr2 org.antlr3 life would be much
> > easier. Sure
> > you wouldn't get auto drop in jar and release, but I'm
> > guessing tooling
> > could make up for that in those cases.
>
> Ironically Java could already support this, there's a reason why a manifest should specify a Specification-Version. It would have been so simple to use this information also to separate classes in a class loader. But the Gods of Java refused to make anything out of it ;-)
>
Surely that would not work for java classes without a manifest - e.g.
classes which are loaded as individual class files rather than from
jars. Not all Java processes use jars.
> - Jörg
>
> ---------------------------------------------------------------------
> 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
RE: Support for OSGi
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Mark Proctor wrote:
> Torsten Curdt wrote:
>>
>> On 21.01.2008, at 10:08, Tom Schindl wrote:
>>
>>> Hi Torsten,
>>>
>>> I understand this but we are seeing many J2EE-Servers adopting OSGi
>>> and many applications (I admit most of them in Eclipse-world) also.
>>> It seems strange to me in those envs to use this "artificial"
>>> package to overcome jar-hell (which is the only reason for the
>>> java5-package right?) they are not having
>>> because of OSGi.
>>
>> Hm.... not sure why its such a big deal to have e.g.
>> o.a.commons.lang2 or similar. If you use an IDE that manages imports
>> you will barely notice anyway.
> personally I've always wondered why having a version attached to the
> namespace hasn't taken off more to deal with api breaking
> releases. if
> we had org.antlr1 org.antlr2 org.antlr3 life would be much
> easier. Sure
> you wouldn't get auto drop in jar and release, but I'm
> guessing tooling
> could make up for that in those cases.
Ironically Java could already support this, there's a reason why a manifest should specify a Specification-Version. It would have been so simple to use this information also to separate classes in a class loader. But the Gods of Java refused to make anything out of it ;-)
- Jörg
---------------------------------------------------------------------
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 Mark Proctor <li...@markproctor.com>.
Torsten Curdt wrote:
>
> On 21.01.2008, at 10:08, Tom Schindl wrote:
>
>> Hi Torsten,
>>
>> I understand this but we are seeing many J2EE-Servers adopting OSGi
>> and many applications
>> (I admit most of them in Eclipse-world) also. It seems strange to me
>> in those envs to use this "artificial"
>> package to overcome jar-hell (which is the only reason for the
>> java5-package right?) they are not having
>> because of OSGi.
>
> Hm.... not sure why its such a big deal to have e.g. o.a.commons.lang2
> or similar. If you use an IDE that manages imports you will barely
> notice anyway.
personally I've always wondered why having a version attached to the
namespace hasn't taken off more to deal with api breaking releases. if
we had org.antlr1 org.antlr2 org.antlr3 life would be much easier. Sure
you wouldn't get auto drop in jar and release, but I'm guessing tooling
could make up for that in those cases.
>
> While it's great that OSGi adoption is getting better I still don't
> believe it's something Commons should rely on. At least that's my
> opinion.
>
> cheers
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
Re: Support for OSGi
Posted by Torsten Curdt <tc...@apache.org>.
On 21.01.2008, at 10:08, Tom Schindl wrote:
> Hi Torsten,
>
> I understand this but we are seeing many J2EE-Servers adopting OSGi
> and many applications
> (I admit most of them in Eclipse-world) also. It seems strange to
> me in those envs to use this "artificial"
> package to overcome jar-hell (which is the only reason for the
> java5-package right?) they are not having
> because of OSGi.
Hm.... not sure why its such a big deal to have e.g.
o.a.commons.lang2 or similar. If you use an IDE that manages imports
you will barely notice anyway.
While it's great that OSGi adoption is getting better I still don't
believe it's something Commons should rely on. At least that's my
opinion.
cheers
--
Torsten
---------------------------------------------------------------------
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 Tom Schindl <li...@bestsolution.at>.
Hi Torsten,
I understand this but we are seeing many J2EE-Servers adopting OSGi and
many applications
(I admit most of them in Eclipse-world) also. It seems strange to me in
those envs to use this "artificial"
package to overcome jar-hell (which is the only reason for the
java5-package right?) they are not having
because of OSGi.
Tom
Torsten Curdt schrieb:
> Not everyone is using OSGi ...so I doubt this is really an option to
> prevent a package shift.
>
> My 2 cents
> --
> Torsten
>
> On 21.01.2008, at 09:13, Tom Schindl wrote:
>
>> Hi,
>>
>> Couldn't this OSGi-adoption made by some commons packages make the
>> package shift for java5 unneeded?
>> With OSGi one can run different versions in the same JVM so its not
>> needed any more.
>>
>> Tom
>>
>> Niall Pemberton schrieb:
>>> On Dec 28, 2007 2:39 PM, Carlos Sanchez <ca...@apache.org> wrote:
>>>
>>>> Two things:
>>>>
>>>> - if the bundle plugin could be released, it'd be great, if not
>>>> projects won't be able to make a release
>>>>
>>>> - my approach to add an osgified manifest to the current project is
>>>> different in order not to change the packaging to bundle. bundle
>>>> packaging only needs to be used to osgify 3rd party libraries. The
>>>> manifest goal of the bundle plugin will generate the OSGi manifest for
>>>> any maven project.
>>>>
>>>
>>> I missed this originally - is there any reason to not use packaging of
>>> "bundle" and let the bundle plugin create the jar?
>>>
>>> Seems like that would be an easy way to turn it on/off for components
>>> (the recommendation for logging was to not do it).
>>>
>>> Niall
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: Support for OSGi
Posted by Torsten Curdt <tc...@apache.org>.
Not everyone is using OSGi ...so I doubt this is really an option to
prevent a package shift.
My 2 cents
--
Torsten
On 21.01.2008, at 09:13, Tom Schindl wrote:
> Hi,
>
> Couldn't this OSGi-adoption made by some commons packages make the
> package shift for java5 unneeded?
> With OSGi one can run different versions in the same JVM so its not
> needed any more.
>
> Tom
>
> Niall Pemberton schrieb:
>> On Dec 28, 2007 2:39 PM, Carlos Sanchez <ca...@apache.org> wrote:
>>
>>> Two things:
>>>
>>> - if the bundle plugin could be released, it'd be great, if not
>>> projects won't be able to make a release
>>>
>>> - my approach to add an osgified manifest to the current project is
>>> different in order not to change the packaging to bundle. bundle
>>> packaging only needs to be used to osgify 3rd party libraries. The
>>> manifest goal of the bundle plugin will generate the OSGi
>>> manifest for
>>> any maven project.
>>>
>>
>> I missed this originally - is there any reason to not use
>> packaging of
>> "bundle" and let the bundle plugin create the jar?
>>
>> Seems like that would be an easy way to turn it on/off for components
>> (the recommendation for logging was to not do it).
>>
>> Niall
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
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 Jörg Schaible <Jo...@Elsag-Solutions.com>.
Tom Schindl wrote:
> Hi,
>
> Couldn't this OSGi-adoption made by some commons packages make the
> package shift for java5 unneeded?
> With OSGi one can run different versions in the same JVM so its not
> needed any more.
Well, there's a world outside of OSGi ...
- Jörg
---------------------------------------------------------------------
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 Tom Schindl <li...@bestsolution.at>.
Hi,
Couldn't this OSGi-adoption made by some commons packages make the
package shift for java5 unneeded?
With OSGi one can run different versions in the same JVM so its not
needed any more.
Tom
Niall Pemberton schrieb:
> On Dec 28, 2007 2:39 PM, Carlos Sanchez <ca...@apache.org> wrote:
>
>> Two things:
>>
>> - if the bundle plugin could be released, it'd be great, if not
>> projects won't be able to make a release
>>
>> - my approach to add an osgified manifest to the current project is
>> different in order not to change the packaging to bundle. bundle
>> packaging only needs to be used to osgify 3rd party libraries. The
>> manifest goal of the bundle plugin will generate the OSGi manifest for
>> any maven project.
>>
>
> I missed this originally - is there any reason to not use packaging of
> "bundle" and let the bundle plugin create the jar?
>
> Seems like that would be an easy way to turn it on/off for components
> (the recommendation for logging was to not do it).
>
> Niall
>
> ---------------------------------------------------------------------
> 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
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 28, 2007 2:39 PM, Carlos Sanchez <ca...@apache.org> wrote:
> Two things:
>
> - if the bundle plugin could be released, it'd be great, if not
> projects won't be able to make a release
>
> - my approach to add an osgified manifest to the current project is
> different in order not to change the packaging to bundle. bundle
> packaging only needs to be used to osgify 3rd party libraries. The
> manifest goal of the bundle plugin will generate the OSGi manifest for
> any maven project.
I missed this originally - is there any reason to not use packaging of
"bundle" and let the bundle plugin create the jar?
Seems like that would be an easy way to turn it on/off for components
(the recommendation for logging was to not do it).
Niall
---------------------------------------------------------------------
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 Carlos Sanchez <ca...@apache.org>.
Two things:
- if the bundle plugin could be released, it'd be great, if not
projects won't be able to make a release
- my approach to add an osgified manifest to the current project is
different in order not to change the packaging to bundle. bundle
packaging only needs to be used to osgify 3rd party libraries. The
manifest goal of the bundle plugin will generate the OSGi manifest for
any maven project.
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<instructions>
<Export-Package>*;version=${pom.version}</Export-Package>
</instructions>
</configuration>
<executions>
<execution>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Needed for including the manifest, see MJAR-71 -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.1</version>
<configuration>
<archive>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
On Dec 28, 2007 1:35 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> in the meantime Stuart fixed the problem with the maven bundleplugin, so
> I think we can give it a test drive :)
>
> Attached is a patch for the parent pom of commons and one to demonstrate
> how to add support for OSGi to commons-lang.
>
> The changes to the parent pom are minimal: it just adds the maven
> bundleplugin from the Apache Felix project. We currently need to use a
> snapshot version, but a release is comming soon.
> Besides adding the plugin, the patch also configures the bundle symbolic
> name for all modules. The symbolic name is the unique identifier which
> should follow java package naming. The best value is to use something
> like "org.apache.commons.{artifactId}" where artifact id is commons-lang
> or commons-collections etc.
>
> The patch to commons lang is also very simple. It changes the parent pom
> to the current snapshot (which includes the changes from above) and sets
> the packaging to bundle - this ensures that the bundleplugin runs and
> creates the resulting jar file. So the bundleplugin replaces the maven
> jar plugin. If you leave the packaging as "jar" the bundleplugin will
> not run.
> The last part of the patch adds the configuration to the bundleplugin.
> The export "*" exports all packages definied in this module for other
> bundles, so all classes are public. All packages are marked with the
> current version which allows to run different versions in parallel.
> The imports are not specified as they are calculated automatically by
> the bundleplugin.
>
> And that's it :)
>
> The changes to the other projects should be similar.
>
>
> Carsten
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
> Index: /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml
> ===================================================================
> --- /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml (revision 605909)
> +++ /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml (working copy)
> @@ -159,6 +159,12 @@
> <artifactId>maven-release-plugin</artifactId>
> <version>2.0-beta-7</version>
> </plugin>
> + <plugin>
> + <groupId>org.apache.felix</groupId>
> + <artifactId>maven-bundle-plugin</artifactId>
> + <version>1.1.0-SNAPSHOT</version>
> + <inherited>true</inherited>
> + </plugin>
> </plugins>
> </pluginManagement>
> <plugins>
> @@ -194,6 +200,15 @@
> <jdkLevel>${maven.compile.source}</jdkLevel>
> </configuration>
> </plugin>
> + <plugin>
> + <groupId>org.apache.felix</groupId>
> + <artifactId>maven-bundle-plugin</artifactId>
> + <configuration>
> + <instructions>
> + <Bundle-SymbolicName>org.apache.commons.${pom.artifactId}</Bundle-SymbolicName>
> + </instructions>
> + </configuration>
> + </plugin>
> </plugins>
> </build>
>
>
> Index: /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml
> ===================================================================
> --- /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml (revision 605909)
> +++ /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml (working copy)
> @@ -22,13 +22,14 @@
> <parent>
> <groupId>org.apache.commons</groupId>
> <artifactId>commons-parent</artifactId>
> - <version>5</version>
> + <version>6-SNAPSHOT</version>
> </parent>
> <modelVersion>4.0.0</modelVersion>
> <groupId>commons-lang</groupId>
> <artifactId>commons-lang</artifactId>
> <version>2.4-SNAPSHOT</version>
> <name>Commons Lang</name>
> + <packaging>bundle</packaging>
>
> <inceptionYear>2001</inceptionYear>
> <description>
> @@ -401,6 +402,16 @@
> <tarLongFileMode>gnu</tarLongFileMode>
> </configuration>
> </plugin>
> + <plugin>
> + <groupId>org.apache.felix</groupId>
> + <artifactId>maven-bundle-plugin</artifactId>
> + <extensions>true</extensions>
> + <configuration>
> + <instructions>
> + <Export-Package>*;version=${pom.version}</Export-Package>
> + </instructions>
> + </configuration>
> + </plugin>
> </plugins>
> </build>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
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 Carsten Ziegeler <cz...@apache.org>.
Niall Pemberton wrote:
> On Dec 28, 2007 12:35 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Hi,
>>
>> in the meantime Stuart fixed the problem with the maven bundleplugin, so
>> I think we can give it a test drive :)
>>
>> Attached is a patch for the parent pom of commons and one to demonstrate
>> how to add support for OSGi to commons-lang.
>
> Thanks for the patches - we have a number of changes to commons-parent
> since the last release so better to get those in a release before we
> add the dependency on the bundleplugin SNAPSHOT - then it won't be
> holding those changes up until the bundleplugin 1.1.0 is released.
> I've just called a vote on releasing commons-parent and if that
> succeeds I plan to then add the bundleplugin and try it out on various
> components.
>
Sounds great, thanks!
We're preparing the release of the bundleplugin, as this requires
releasing some other stuff before, I guess we'll make it sometime in
January.
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
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 28, 2007 12:35 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> in the meantime Stuart fixed the problem with the maven bundleplugin, so
> I think we can give it a test drive :)
>
> Attached is a patch for the parent pom of commons and one to demonstrate
> how to add support for OSGi to commons-lang.
Thanks for the patches - we have a number of changes to commons-parent
since the last release so better to get those in a release before we
add the dependency on the bundleplugin SNAPSHOT - then it won't be
holding those changes up until the bundleplugin 1.1.0 is released.
I've just called a vote on releasing commons-parent and if that
succeeds I plan to then add the bundleplugin and try it out on various
components.
Niall
> The changes to the parent pom are minimal: it just adds the maven
> bundleplugin from the Apache Felix project. We currently need to use a
> snapshot version, but a release is comming soon.
> Besides adding the plugin, the patch also configures the bundle symbolic
> name for all modules. The symbolic name is the unique identifier which
> should follow java package naming. The best value is to use something
> like "org.apache.commons.{artifactId}" where artifact id is commons-lang
> or commons-collections etc.
>
> The patch to commons lang is also very simple. It changes the parent pom
> to the current snapshot (which includes the changes from above) and sets
> the packaging to bundle - this ensures that the bundleplugin runs and
> creates the resulting jar file. So the bundleplugin replaces the maven
> jar plugin. If you leave the packaging as "jar" the bundleplugin will
> not run.
> The last part of the patch adds the configuration to the bundleplugin.
> The export "*" exports all packages definied in this module for other
> bundles, so all classes are public. All packages are marked with the
> current version which allows to run different versions in parallel.
> The imports are not specified as they are calculated automatically by
> the bundleplugin.
>
> And that's it :)
>
> The changes to the other projects should be similar.
>
>
> Carsten
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
> Index: /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml
> ===================================================================
> --- /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml (revision 605909)
> +++ /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml (working copy)
> @@ -159,6 +159,12 @@
> <artifactId>maven-release-plugin</artifactId>
> <version>2.0-beta-7</version>
> </plugin>
> + <plugin>
> + <groupId>org.apache.felix</groupId>
> + <artifactId>maven-bundle-plugin</artifactId>
> + <version>1.1.0-SNAPSHOT</version>
> + <inherited>true</inherited>
> + </plugin>
> </plugins>
> </pluginManagement>
> <plugins>
> @@ -194,6 +200,15 @@
> <jdkLevel>${maven.compile.source}</jdkLevel>
> </configuration>
> </plugin>
> + <plugin>
> + <groupId>org.apache.felix</groupId>
> + <artifactId>maven-bundle-plugin</artifactId>
> + <configuration>
> + <instructions>
> + <Bundle-SymbolicName>org.apache.commons.${pom.artifactId}</Bundle-SymbolicName>
> + </instructions>
> + </configuration>
> + </plugin>
> </plugins>
> </build>
>
>
> Index: /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml
> ===================================================================
> --- /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml (revision 605909)
> +++ /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml (working copy)
> @@ -22,13 +22,14 @@
> <parent>
> <groupId>org.apache.commons</groupId>
> <artifactId>commons-parent</artifactId>
> - <version>5</version>
> + <version>6-SNAPSHOT</version>
> </parent>
> <modelVersion>4.0.0</modelVersion>
> <groupId>commons-lang</groupId>
> <artifactId>commons-lang</artifactId>
> <version>2.4-SNAPSHOT</version>
> <name>Commons Lang</name>
> + <packaging>bundle</packaging>
>
> <inceptionYear>2001</inceptionYear>
> <description>
> @@ -401,6 +402,16 @@
> <tarLongFileMode>gnu</tarLongFileMode>
> </configuration>
> </plugin>
> + <plugin>
> + <groupId>org.apache.felix</groupId>
> + <artifactId>maven-bundle-plugin</artifactId>
> + <extensions>true</extensions>
> + <configuration>
> + <instructions>
> + <Export-Package>*;version=${pom.version}</Export-Package>
> + </instructions>
> + </configuration>
> + </plugin>
> </plugins>
> </build>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Support for OSGi
Posted by Carsten Ziegeler <cz...@apache.org>.
Henri Yandell wrote:
>
> Guess that means Lang should start using m2 and not m1 for the release :)
:)
It's also possible to add the meta information to the jar "by hand". So
you could look at the result of the m2 build and then add the manifest
entries by hand using the m1 build - it's not that flexible and elegant
but working as well :)
>
> Dumb question - why does anything need to be added to the child pom?
> Can't it all go in the parent pom?
Yes, that's actually a good question :)
For libraries like lang or collections the changes to the pom will all
look the same. You define the exports of the library by exporting all
contained classes.
For other products at commons this might be different as not all
contained classes might be meant to be public, so you would only export
the public packages (api and util classes) while you would not export
private packages (implementations). In these cases each project has to
explicitly declare the public and the private packages.
But we could move the default (exporting everything) to the parent pom
and then the only change would be to change the packaging from jar to
bundle in each project.
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
Re: Support for OSGi
Posted by Henri Yandell <fl...@gmail.com>.
On Dec 28, 2007 4:35 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> in the meantime Stuart fixed the problem with the maven bundleplugin, so
> I think we can give it a test drive :)
>
> Attached is a patch for the parent pom of commons and one to demonstrate
> how to add support for OSGi to commons-lang.
>
> The changes to the parent pom are minimal: it just adds the maven
> bundleplugin from the Apache Felix project. We currently need to use a
> snapshot version, but a release is comming soon.
> Besides adding the plugin, the patch also configures the bundle symbolic
> name for all modules. The symbolic name is the unique identifier which
> should follow java package naming. The best value is to use something
> like "org.apache.commons.{artifactId}" where artifact id is commons-lang
> or commons-collections etc.
>
> The patch to commons lang is also very simple. It changes the parent pom
> to the current snapshot (which includes the changes from above) and sets
> the packaging to bundle - this ensures that the bundleplugin runs and
> creates the resulting jar file. So the bundleplugin replaces the maven
> jar plugin. If you leave the packaging as "jar" the bundleplugin will
> not run.
> The last part of the patch adds the configuration to the bundleplugin.
> The export "*" exports all packages definied in this module for other
> bundles, so all classes are public. All packages are marked with the
> current version which allows to run different versions in parallel.
> The imports are not specified as they are calculated automatically by
> the bundleplugin.
Guess that means Lang should start using m2 and not m1 for the release :)
Dumb question - why does anything need to be added to the child pom?
Can't it all go in the parent pom?
Hen
---------------------------------------------------------------------
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 Carsten Ziegeler <cz...@apache.org>.
Hi,
in the meantime Stuart fixed the problem with the maven bundleplugin, so
I think we can give it a test drive :)
Attached is a patch for the parent pom of commons and one to demonstrate
how to add support for OSGi to commons-lang.
The changes to the parent pom are minimal: it just adds the maven
bundleplugin from the Apache Felix project. We currently need to use a
snapshot version, but a release is comming soon.
Besides adding the plugin, the patch also configures the bundle symbolic
name for all modules. The symbolic name is the unique identifier which
should follow java package naming. The best value is to use something
like "org.apache.commons.{artifactId}" where artifact id is commons-lang
or commons-collections etc.
The patch to commons lang is also very simple. It changes the parent pom
to the current snapshot (which includes the changes from above) and sets
the packaging to bundle - this ensures that the bundleplugin runs and
creates the resulting jar file. So the bundleplugin replaces the maven
jar plugin. If you leave the packaging as "jar" the bundleplugin will
not run.
The last part of the patch adds the configuration to the bundleplugin.
The export "*" exports all packages definied in this module for other
bundles, so all classes are public. All packages are marked with the
current version which allows to run different versions in parallel.
The imports are not specified as they are calculated automatically by
the bundleplugin.
And that's it :)
The changes to the other projects should be similar.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Support for OSGi
Posted by Carsten Ziegeler <cz...@apache.org>.
nicolas de loof schrieb:
> I also got some troubles when (quick) testing the felix bundle-plugin :
> I have configured the maven-jar-plugin to set some custom MANIFEST entries
> (in my case, the SVN revision number as Build-Revision). When using the
> felix plugin, my MANIFEST is replaced by OSGi one, not merged.
>
> But maybe I missed some configuration ? Or maybe this requires enhancement
> in the bundle plugin ?
>
Yes, I think this is a problem with the bundle plugin. I'll figure this
out and we can hopefully fix this in the bundle plugin.
> That beeing said, thanks to this plugin, making a m2 project OSGi compliant
> seems really easy as many of the required meta-datas are allready available
> in pom. I think this is a good point in OSGi adoption.
>
:)
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
Re: Support for OSGi
Posted by nicolas de loof <ni...@apache.org>.
I also got some troubles when (quick) testing the felix bundle-plugin :
I have configured the maven-jar-plugin to set some custom MANIFEST entries
(in my case, the SVN revision number as Build-Revision). When using the
felix plugin, my MANIFEST is replaced by OSGi one, not merged.
But maybe I missed some configuration ? Or maybe this requires enhancement
in the bundle plugin ?
That beeing said, thanks to this plugin, making a m2 project OSGi compliant
seems really easy as many of the required meta-datas are allready available
in pom. I think this is a good point in OSGi adoption.
Nico.
2007/12/20, Carsten Ziegeler <cz...@apache.org>:
>
> Thanks for the very positive response so far! Great!
>
> I'll come up with some patches for some of the commons projects; there
> is a minor problem as the current commons parent pom defines the
> manifest entries, but I think that we can come up with a solution for
> this.
>
> 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
>
>
Re: Support for OSGi
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks for the very positive response so far! Great!
I'll come up with some patches for some of the commons projects; there
is a minor problem as the current commons parent pom defines the
manifest entries, but I think that we can come up with a solution for this.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Support for OSGi
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks for the very positive response so far! Great!
I'll come up with some patches for some of the commons projects; there
is a minor problem as the current commons parent pom defines the
manifest entries, but I think that we can come up with a solution for this.
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
Re: Support for OSGi
Posted by Torsten Curdt <tc...@apache.org>.
In general I think it's a good idea. Happy to help and apply patches.
cheers
--
Torsten
>> 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
Re: Support for OSGi
Posted by Stuart McCulloch <st...@jayway.net>.
On 20/12/2007, Niall Pemberton <ni...@gmail.com> wrote:
>
> We have a mixed bag of build systems here at commons. Until recently
> we were pretty much maven1, with the odd ant/maven1 mixture. A few
> components have m2 builds that have been used in anger and recently we
> added m2 builds for all but 2 of the remaining components. However
> there has been no commons-wide decision to make m2 the primary build
> system and its quite likely that there will be future releases using
> m1.
FYI, the maven-bundle-plugin uses Peter Kriens' BND tool to generate
the OSGi headers - BND can also be used as a command-line tool, as
well as an Ant task: http://aqute.biz/Code/Bnd
( the BND tool is also used by the 'maven-osgi' shared component )
--
Cheers, Stuart
Re: Support for OSGi
Posted by Stuart McCulloch <st...@jayway.net>.
On 20/12/2007, Niall Pemberton <ni...@gmail.com> wrote:
>
> We have a mixed bag of build systems here at commons. Until recently
> we were pretty much maven1, with the odd ant/maven1 mixture. A few
> components have m2 builds that have been used in anger and recently we
> added m2 builds for all but 2 of the remaining components. However
> there has been no commons-wide decision to make m2 the primary build
> system and its quite likely that there will be future releases using
> m1.
FYI, the maven-bundle-plugin uses Peter Kriens' BND tool to generate
the OSGi headers - BND can also be used as a command-line tool, as
well as an Ant task: http://aqute.biz/Code/Bnd
( the BND tool is also used by the 'maven-osgi' shared component )
--
Cheers, Stuart
Re: Support for OSGi
Posted by Torsten Curdt <tc...@apache.org>.
In general I think it's a good idea. Happy to help and apply patches.
cheers
--
Torsten
>> 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
---------------------------------------------------------------------
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 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.
+1 in principle and I'm happy to help do the work or apply patches.
Don't have great deal of OSGi knowledge - just attended a presentation
and went through a tutorial.
> 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.
We have a mixed bag of build systems here at commons. Until recently
we were pretty much maven1, with the odd ant/maven1 mixture. A few
components have m2 builds that have been used in anger and recently we
added m2 builds for all but 2 of the remaining components. However
there has been no commons-wide decision to make m2 the primary build
system and its quite likely that there will be future releases using
m1.
Thats the background and I would suggest that we focus on modifying
the m2 builds to support OSGi. Each component's pom inherits from
commons-parent[1] - is this something that could be configured there
or does it need doing on a component-by-component basis? Perhaps you
could either provide a patch for Commons parent - or an example for
one component's pom so that we can get a better idea of what's
involved to make this work.
Niall
[1] http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml
> 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
Re: Support for OSGi
Posted by Tom Schindl <li...@bestsolution.at>.
What a great idea this would be nice for me as RCP developer because
currently I have to create my
own bundles from the commons-packages.
Tom
Carsten Ziegeler schrieb:
> 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
>
Re: Support for OSGi
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 31 December 2007 14:57, Alan D. Cabrera wrote:
> I'm sorry but I'm not completely following. What problems does this
> create? How is it counter-productive.
Commons-logging is not designed for
a) OSGi environment with classes loaded and unloaded in runtime.
b) Unifying Commons-logging, Log4J, SLF4J, Avalon Logging API, KF Log API,
JDK Logging API and OSGi's own Log service API, to be routed to the
same logging backend.
When we did the Pax Logging system, we addressed the above very seriously and
have a solution that works, BUT it required us to high-jack the
commons-logging API namespace and interfaces (that goes for Log4J as well),
and it is possible to crash Pax Logging by installing commons-logging
packages in parallel (unless the user remembers to do
a "provider=paxlogging;mandatory:=provider" in the ImportPackage).
I have not checked the implementation details on commons-logging recently, but
older versions have been one of the largest single cause of "wasted time" in
Java history, with its class caching and runtime "detection" of logging
system to use. I suspect that some of that has been corrected, but I likewise
suspect that it there are still many problems for the OSGi environment, which
will be hard to track/find for the average user. A quick look at LogFactory,
and I am pretty convinced that I my suspicion is accurate.
Personally, I think the "Logging scene" is absurd...
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Support for OSGi
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 31 December 2007 14:57, Alan D. Cabrera wrote:
> I'm sorry but I'm not completely following. What problems does this
> create? How is it counter-productive.
Commons-logging is not designed for
a) OSGi environment with classes loaded and unloaded in runtime.
b) Unifying Commons-logging, Log4J, SLF4J, Avalon Logging API, KF Log API,
JDK Logging API and OSGi's own Log service API, to be routed to the
same logging backend.
When we did the Pax Logging system, we addressed the above very seriously and
have a solution that works, BUT it required us to high-jack the
commons-logging API namespace and interfaces (that goes for Log4J as well),
and it is possible to crash Pax Logging by installing commons-logging
packages in parallel (unless the user remembers to do
a "provider=paxlogging;mandatory:=provider" in the ImportPackage).
I have not checked the implementation details on commons-logging recently, but
older versions have been one of the largest single cause of "wasted time" in
Java history, with its class caching and runtime "detection" of logging
system to use. I suspect that some of that has been corrected, but I likewise
suspect that it there are still many problems for the OSGi environment, which
will be hard to track/find for the average user. A quick look at LogFactory,
and I am pretty convinced that I my suspicion is accurate.
Personally, I think the "Logging scene" is absurd...
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
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 "Alan D. Cabrera" <li...@toolazydogs.com>.
On Dec 30, 2007, at 10:10 PM, Niclas Hedhman wrote:
> On Thursday 20 December 2007 03:28, simon wrote:
>> If you provide patches, I'm happy to apply them for commons-logging
>> and
>> commons-digester.
>
> Please do not do this for commons-logging. Pax Logging provides the
> commons-logging API, and hooks into a unified logging framework
> specifically
> designed to deal with OSGi. By providing a apparent OSGi bundle,
> which in
> reality will only create more problems than it solves is IMNSHO
> counter-productive.
I'm sorry but I'm not completely following. What problems does this
create? How is it counter-productive.
Regards,
Alan
Re: Support for OSGi
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Dec 30, 2007, at 10:10 PM, Niclas Hedhman wrote:
> On Thursday 20 December 2007 03:28, simon wrote:
>> If you provide patches, I'm happy to apply them for commons-logging
>> and
>> commons-digester.
>
> Please do not do this for commons-logging. Pax Logging provides the
> commons-logging API, and hooks into a unified logging framework
> specifically
> designed to deal with OSGi. By providing a apparent OSGi bundle,
> which in
> reality will only create more problems than it solves is IMNSHO
> counter-productive.
I'm sorry but I'm not completely following. What problems does this
create? How is it counter-productive.
Regards,
Alan
---------------------------------------------------------------------
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 Niclas Hedhman <ni...@hedhman.org>.
On Thursday 20 December 2007 03:28, simon wrote:
> If you provide patches, I'm happy to apply them for commons-logging and
> commons-digester.
Please do not do this for commons-logging. Pax Logging provides the
commons-logging API, and hooks into a unified logging framework specifically
designed to deal with OSGi. By providing a apparent OSGi bundle, which in
reality will only create more problems than it solves is IMNSHO
counter-productive.
Thanks
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Support for OSGi
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 20 December 2007 03:28, simon wrote:
> If you provide patches, I'm happy to apply them for commons-logging and
> commons-digester.
Please do not do this for commons-logging. Pax Logging provides the
commons-logging API, and hooks into a unified logging framework specifically
designed to deal with OSGi. By providing a apparent OSGi bundle, which in
reality will only create more problems than it solves is IMNSHO
counter-productive.
Thanks
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
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 simon <si...@chello.at>.
On Wed, 2007-12-19 at 15:38 +0100, Carsten Ziegeler 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.
If you provide patches, I'm happy to apply them for commons-logging and
commons-digester.
I don't have a clue how OSGi works (or why it uses WEIrd CAPitals), but
if you provide patches I'm happz to apply them to commons-logging and
commons-digester.
Note that commons-logging has some unusual dependency structures, so be
careful with the meta-data for it. Digester is an ordinary library
though.
Regards,
Simon
---------------------------------------------------------------------
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 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.
+1 in principle and I'm happy to help do the work or apply patches.
Don't have great deal of OSGi knowledge - just attended a presentation
and went through a tutorial.
> 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.
We have a mixed bag of build systems here at commons. Until recently
we were pretty much maven1, with the odd ant/maven1 mixture. A few
components have m2 builds that have been used in anger and recently we
added m2 builds for all but 2 of the remaining components. However
there has been no commons-wide decision to make m2 the primary build
system and its quite likely that there will be future releases using
m1.
Thats the background and I would suggest that we focus on modifying
the m2 builds to support OSGi. Each component's pom inherits from
commons-parent[1] - is this something that could be configured there
or does it need doing on a component-by-component basis? Perhaps you
could either provide a patch for Commons parent - or an example for
one component's pom so that we can get a better idea of what's
involved to make this work.
Niall
[1] http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml
> 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
>
>
Re: Support for OSGi
Posted by simon <si...@chello.at>.
On Wed, 2007-12-19 at 15:38 +0100, Carsten Ziegeler 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.
If you provide patches, I'm happy to apply them for commons-logging and
commons-digester.
I don't have a clue how OSGi works (or why it uses WEIrd CAPitals), but
if you provide patches I'm happz to apply them to commons-logging and
commons-digester.
Note that commons-logging has some unusual dependency structures, so be
careful with the meta-data for it. Digester is an ordinary library
though.
Regards,
Simon
Re: Support for OSGi
Posted by Tom Schindl <li...@bestsolution.at>.
What a great idea this would be nice for me as RCP developer because
currently I have to create my
own bundles from the commons-packages.
Tom
Carsten Ziegeler schrieb:
> 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
>
---------------------------------------------------------------------
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 31/01/2008, Niall Pemberton <ni...@gmail.com> wrote:
>
> These isn't much OSGi knowledge here in commons - we're doing this at
> the request of the Apache Felix project so that they don't have to
> re-package our artifacts for OSGi. So I'm hoping that someone from
> Felix will pick up your second and third points :)
(I've answered the 2nd/3rd points in another reply...)
Btw, on behalf of OSGi users thanks for taking the time to add the OSGi
metadata.
It will be so great to be able to just drop commons jars straight onto a
framework.
We've had two releases recently with OSGi info (Commons Pool 1.4 and
> Commons IO 1.4) and we have a wiki page to track progress here (which
> hopefully we'll keep up-to-date):
>
> http://wiki.apache.org/commons/CommonsOsgi
>
> Thanks for the feedback, much appreciated.
Agreed, any feedback is really appreciated as it helps improve things for
all users.
--
Cheers, Stuart
Re: Support for OSGi
Posted by Stuart McCulloch <st...@jayway.net>.
On 31/01/2008, Niall Pemberton <ni...@gmail.com> wrote:
>
> These isn't much OSGi knowledge here in commons - we're doing this at
> the request of the Apache Felix project so that they don't have to
> re-package our artifacts for OSGi. So I'm hoping that someone from
> Felix will pick up your second and third points :)
(I've answered the 2nd/3rd points in another reply...)
Btw, on behalf of OSGi users thanks for taking the time to add the OSGi
metadata.
It will be so great to be able to just drop commons jars straight onto a
framework.
We've had two releases recently with OSGi info (Commons Pool 1.4 and
> Commons IO 1.4) and we have a wiki page to track progress here (which
> hopefully we'll keep up-to-date):
>
> http://wiki.apache.org/commons/CommonsOsgi
>
> Thanks for the feedback, much appreciated.
Agreed, any feedback is really appreciated as it helps improve things for
all users.
--
Cheers, Stuart
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 31, 2008 1:52 PM, 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 have adjusted the maven plugin config so that these are not included
- new versions of the net (and launcher) jar and manifest are
available for review in the same place:
http://people.apache.org/~niallp/commons-osgi/
> 2. Import-Package: org.apache.commons.net.smtp
> this is also wrong though less destructive.
> commons.net.smtp is really exported and not imported.
>
> 3. Export-Package:
> org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.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.
>
> I guess that these should perhaps really be bug
> reports against the Bnd utility which autogenerated
> the Manifest; Tool: Bnd-0.0.227.
These isn't much OSGi knowledge here in commons - we're doing this at
the request of the Apache Felix project so that they don't have to
re-package our artifacts for OSGi. So I'm hoping that someone from
Felix will pick up your second and third points :)
> 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.
>
> Anyways, if there is a plan to make a downloadable
> release of any commons packages with OSGi info
> added, I'd like to know.
We've had two releases recently with OSGi info (Commons Pool 1.4 and
Commons IO 1.4) and we have a wiki page to track progress here (which
hopefully we'll keep up-to-date):
http://wiki.apache.org/commons/CommonsOsgi
Thanks for the feedback, much appreciated.
Niall
> 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 1, 2008 4:07 PM, Stuart McCulloch <st...@jayway.net> wrote:
> On 01/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> >
> > Would it be possible to add bnd 0.0.236 to the maven repo so I can try
> > out these new features with Felix's bundle plugin?
> >
> > http://repo1.maven.org/maven2/biz/aQute/bndlib/
>
> FYI, this is already in progress - Carlos Sanchez is sorting out the upload
OK thanks :)
Niall
> --
> Cheers, Stuart
>
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 1, 2008 4:07 PM, Stuart McCulloch <st...@jayway.net> wrote:
> On 01/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> >
> > Would it be possible to add bnd 0.0.236 to the maven repo so I can try
> > out these new features with Felix's bundle plugin?
> >
> > http://repo1.maven.org/maven2/biz/aQute/bndlib/
>
> FYI, this is already in progress - Carlos Sanchez is sorting out the upload
OK thanks :)
Niall
> --
> 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:
>
> Would it be possible to add bnd 0.0.236 to the maven repo so I can try
> out these new features with Felix's bundle plugin?
>
> http://repo1.maven.org/maven2/biz/aQute/bndlib/
FYI, this is already in progress - Carlos Sanchez is sorting out the upload
--
Cheers, Stuart
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 31, 2008 3:01 PM, Peter Kriens <Pe...@aqute.biz> wrote:
> > It's useless to add a "uses" directive for
> > packages that are in the same bundle.
> It is also harmless ... Besides, the important issue is that it lists
> private packages, which is not wrong but useless.
>
> > At
> > Eclipse-Orbit, we've found problems with "uses"
> > and decided to no longer use it.
> Well, Equinox seems to have problems with large sets of bundles. It
> should be trivial to remove the extraneous uses before the resolver
> uses them. Apache Felix seems to do ok as far as I know? I think not
> putting the uses: directive in there is the wrong way around. It is
> then better to ignore them in Equinox, I think there is a flag for this.
>
> > I guess that these should perhaps really be bug
> > reports against the Bnd utility which autogenerated
> > the Manifest; Tool: Bnd-0.0.227.
> It is not a bug but a new feature. At the request of Stuart Mcculloch
> I have added the following features to bnd 0.0.236
Would it be possible to add bnd 0.0.236 to the maven repo so I can try
out these new features with Felix's bundle plugin?
http://repo1.maven.org/maven2/biz/aQute/bndlib/
Niall
> - A -nouses: true/false clause
> - A possibility to set a uses: directive on an Export-Package or -
> exportcontents instruction
> - All uses are now filtered by the export + imports of a bundle.
>
> > 2. Import-Package: org.apache.commons.net.smtp
> > this is also wrong though less destructive.
> > commons.net.smtp is really exported and not imported.
> Bnd automatically imports all exports to allow substitutability. If
> you do not do this, you create all kinds of standalone class spaces
> and things will not work together. It is generally bad practice to
> only export a package.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> On 31 jan 2008, at 14:52, Oberhuber, Martin 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.
> >
> > 2. Import-Package: org.apache.commons.net.smtp
> > this is also wrong though less destructive.
> > commons.net.smtp is really exported and not imported.
> >
> > 3. Export-Package:
> > org
> > .apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.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.
> >
> > I guess that these should perhaps really be bug
> > reports against the Bnd utility which autogenerated
> > the Manifest; Tool: Bnd-0.0.227.
> >
> > 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.
> >
> > 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
> >>
> >>
>
>
---------------------------------------------------------------------
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 Jan 31, 2008 3:01 PM, Peter Kriens <Pe...@aqute.biz> wrote:
> > It's useless to add a "uses" directive for
> > packages that are in the same bundle.
> It is also harmless ... Besides, the important issue is that it lists
> private packages, which is not wrong but useless.
>
> > At
> > Eclipse-Orbit, we've found problems with "uses"
> > and decided to no longer use it.
> Well, Equinox seems to have problems with large sets of bundles. It
> should be trivial to remove the extraneous uses before the resolver
> uses them. Apache Felix seems to do ok as far as I know? I think not
> putting the uses: directive in there is the wrong way around. It is
> then better to ignore them in Equinox, I think there is a flag for this.
>
> > I guess that these should perhaps really be bug
> > reports against the Bnd utility which autogenerated
> > the Manifest; Tool: Bnd-0.0.227.
> It is not a bug but a new feature. At the request of Stuart Mcculloch
> I have added the following features to bnd 0.0.236
Would it be possible to add bnd 0.0.236 to the maven repo so I can try
out these new features with Felix's bundle plugin?
http://repo1.maven.org/maven2/biz/aQute/bndlib/
Niall
> - A -nouses: true/false clause
> - A possibility to set a uses: directive on an Export-Package or -
> exportcontents instruction
> - All uses are now filtered by the export + imports of a bundle.
>
> > 2. Import-Package: org.apache.commons.net.smtp
> > this is also wrong though less destructive.
> > commons.net.smtp is really exported and not imported.
> Bnd automatically imports all exports to allow substitutability. If
> you do not do this, you create all kinds of standalone class spaces
> and things will not work together. It is generally bad practice to
> only export a package.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> On 31 jan 2008, at 14:52, Oberhuber, Martin 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.
> >
> > 2. Import-Package: org.apache.commons.net.smtp
> > this is also wrong though less destructive.
> > commons.net.smtp is really exported and not imported.
> >
> > 3. Export-Package:
> > org
> > .apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.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.
> >
> > I guess that these should perhaps really be bug
> > reports against the Bnd utility which autogenerated
> > the Manifest; Tool: Bnd-0.0.227.
> >
> > 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.
> >
> > 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
> >>
> >>
>
>
Re: Support for OSGi
Posted by Peter Kriens <Pe...@aQute.biz>.
> It's useless to add a "uses" directive for
> packages that are in the same bundle.
It is also harmless ... Besides, the important issue is that it lists
private packages, which is not wrong but useless.
> At
> Eclipse-Orbit, we've found problems with "uses"
> and decided to no longer use it.
Well, Equinox seems to have problems with large sets of bundles. It
should be trivial to remove the extraneous uses before the resolver
uses them. Apache Felix seems to do ok as far as I know? I think not
putting the uses: directive in there is the wrong way around. It is
then better to ignore them in Equinox, I think there is a flag for this.
> I guess that these should perhaps really be bug
> reports against the Bnd utility which autogenerated
> the Manifest; Tool: Bnd-0.0.227.
It is not a bug but a new feature. At the request of Stuart Mcculloch
I have added the following features to bnd 0.0.236
- A -nouses: true/false clause
- A possibility to set a uses: directive on an Export-Package or -
exportcontents instruction
- All uses are now filtered by the export + imports of a bundle.
> 2. Import-Package: org.apache.commons.net.smtp
> this is also wrong though less destructive.
> commons.net.smtp is really exported and not imported.
Bnd automatically imports all exports to allow substitutability. If
you do not do this, you create all kinds of standalone class spaces
and things will not work together. It is generally bad practice to
only export a package.
Kind regards,
Peter Kriens
On 31 jan 2008, at 14:52, Oberhuber, Martin 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.
>
> 2. Import-Package: org.apache.commons.net.smtp
> this is also wrong though less destructive.
> commons.net.smtp is really exported and not imported.
>
> 3. Export-Package:
> org
> .apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.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.
>
> I guess that these should perhaps really be bug
> reports against the Bnd utility which autogenerated
> the Manifest; Tool: Bnd-0.0.227.
>
> 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.
>
> 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
>>
>>
Re: Support for OSGi
Posted by Peter Kriens <Pe...@aQute.biz>.
> It's useless to add a "uses" directive for
> packages that are in the same bundle.
It is also harmless ... Besides, the important issue is that it lists
private packages, which is not wrong but useless.
> At
> Eclipse-Orbit, we've found problems with "uses"
> and decided to no longer use it.
Well, Equinox seems to have problems with large sets of bundles. It
should be trivial to remove the extraneous uses before the resolver
uses them. Apache Felix seems to do ok as far as I know? I think not
putting the uses: directive in there is the wrong way around. It is
then better to ignore them in Equinox, I think there is a flag for this.
> I guess that these should perhaps really be bug
> reports against the Bnd utility which autogenerated
> the Manifest; Tool: Bnd-0.0.227.
It is not a bug but a new feature. At the request of Stuart Mcculloch
I have added the following features to bnd 0.0.236
- A -nouses: true/false clause
- A possibility to set a uses: directive on an Export-Package or -
exportcontents instruction
- All uses are now filtered by the export + imports of a bundle.
> 2. Import-Package: org.apache.commons.net.smtp
> this is also wrong though less destructive.
> commons.net.smtp is really exported and not imported.
Bnd automatically imports all exports to allow substitutability. If
you do not do this, you create all kinds of standalone class spaces
and things will not work together. It is generally bad practice to
only export a package.
Kind regards,
Peter Kriens
On 31 jan 2008, at 14:52, Oberhuber, Martin 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.
>
> 2. Import-Package: org.apache.commons.net.smtp
> this is also wrong though less destructive.
> commons.net.smtp is really exported and not imported.
>
> 3. Export-Package:
> org
> .apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.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.
>
> I guess that these should perhaps really be bug
> reports against the Bnd utility which autogenerated
> the Manifest; Tool: Bnd-0.0.227.
>
> 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.
>
> 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
>>
>>
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
RE: Support for OSGi
Posted by "Oberhuber, Martin" <Ma...@windriver.com>.
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 "Oberhuber, Martin" <Ma...@windriver.com>.
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
>
Re: Support for OSGi
Posted by Stuart McCulloch <st...@jayway.net>.
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,org.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
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 31, 2008 1:52 PM, 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 have adjusted the maven plugin config so that these are not included
- new versions of the net (and launcher) jar and manifest are
available for review in the same place:
http://people.apache.org/~niallp/commons-osgi/
> 2. Import-Package: org.apache.commons.net.smtp
> this is also wrong though less destructive.
> commons.net.smtp is really exported and not imported.
>
> 3. Export-Package:
> org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.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.
>
> I guess that these should perhaps really be bug
> reports against the Bnd utility which autogenerated
> the Manifest; Tool: Bnd-0.0.227.
These isn't much OSGi knowledge here in commons - we're doing this at
the request of the Apache Felix project so that they don't have to
re-package our artifacts for OSGi. So I'm hoping that someone from
Felix will pick up your second and third points :)
> 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.
>
> Anyways, if there is a plan to make a downloadable
> release of any commons packages with OSGi info
> added, I'd like to know.
We've had two releases recently with OSGi info (Commons Pool 1.4 and
Commons IO 1.4) and we have a wiki page to track progress here (which
hopefully we'll keep up-to-date):
http://wiki.apache.org/commons/CommonsOsgi
Thanks for the feedback, much appreciated.
Niall
> 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
> >
> >
>
> ---------------------------------------------------------------------
> 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 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,org.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
RE: Support for OSGi
Posted by "Oberhuber, Martin" <Ma...@windriver.com>.
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.
2. Import-Package: org.apache.commons.net.smtp
this is also wrong though less destructive.
commons.net.smtp is really exported and not imported.
3. Export-Package:
org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.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.
I guess that these should perhaps really be bug
reports against the Bnd utility which autogenerated
the Manifest; Tool: Bnd-0.0.227.
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.
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
>
>
---------------------------------------------------------------------
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 "Oberhuber, Martin" <Ma...@windriver.com>.
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.
2. Import-Package: org.apache.commons.net.smtp
this is also wrong though less destructive.
commons.net.smtp is really exported and not imported.
3. Export-Package:
org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.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.
I guess that these should perhaps really be bug
reports against the Bnd utility which autogenerated
the Manifest; Tool: Bnd-0.0.227.
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.
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
>
>
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
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
Re: Support for OSGi
Posted by Niall Pemberton <ni...@gmail.com>.
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
>
>
Re: Support for OSGi
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Carsten Ziegeler wrote:
> 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.
I think that this is a really good idea, benefitting both us and OSGi.
If maven 2 can generate all this for us, then it might be the push
needed to switch commons to maven 2 (although we mustn't underestimate
that task).
The concern has to be the lack of real OSGi knowledge within commons.
So, support from external experts will be a necessity.
Stephen
---------------------------------------------------------------------
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 Carsten Ziegeler <cz...@apache.org>.
nicolas de loof wrote:
> Could such support be added using maven-osgi ?
> (https://svn.apache.org/repos/asf/maven/shared/trunk/maven-osgi/)
This artifact contains some utility code - in fact it is used by the
Felix bundleplugin
http://svn.apache.org/repos/asf/felix/trunk/bundleplugin
So, you need the bundleplugin.
> I've never used it myself, but from what I've read on osgi, the bundle
> meta-datas could be created based on the POM (for modules depdendencies,
> version, etc..) Just the public API needs to be set in any way.
Yes, exactly - it's not that much you have to define.
>
> The felix wrappers (http://svn.apache.org/repos/asf/felix/trunk/commons/)
> use a custom bundle packaging based on felix maven-bundle-plugin. How to
> this tooling overlap with maven-osgi ?
The maven-bundle-plugin is the one to use (as outlined above)
>
> Latest question, why not just provide the required MANIFEST entries (or
> plugin configuration) as patch ? All the required work seems to have been
> done on felix side !
Yes, that's basically our idea - on the other hand, we don't want to
provide all the patches when there is no interest in applying them :)
So, this thread is about checking interest :) and perhaps some of the
commons projects want to do it on their own :)
Carsten
>
> Nico.
>
> 2007/12/19, Carsten Ziegeler <cz...@apache.org>:
>> 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
>>
>>
>
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
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 Carsten Ziegeler <cz...@apache.org>.
nicolas de loof wrote:
> Could such support be added using maven-osgi ?
> (https://svn.apache.org/repos/asf/maven/shared/trunk/maven-osgi/)
This artifact contains some utility code - in fact it is used by the
Felix bundleplugin
http://svn.apache.org/repos/asf/felix/trunk/bundleplugin
So, you need the bundleplugin.
> I've never used it myself, but from what I've read on osgi, the bundle
> meta-datas could be created based on the POM (for modules depdendencies,
> version, etc..) Just the public API needs to be set in any way.
Yes, exactly - it's not that much you have to define.
>
> The felix wrappers (http://svn.apache.org/repos/asf/felix/trunk/commons/)
> use a custom bundle packaging based on felix maven-bundle-plugin. How to
> this tooling overlap with maven-osgi ?
The maven-bundle-plugin is the one to use (as outlined above)
>
> Latest question, why not just provide the required MANIFEST entries (or
> plugin configuration) as patch ? All the required work seems to have been
> done on felix side !
Yes, that's basically our idea - on the other hand, we don't want to
provide all the patches when there is no interest in applying them :)
So, this thread is about checking interest :) and perhaps some of the
commons projects want to do it on their own :)
Carsten
>
> Nico.
>
> 2007/12/19, Carsten Ziegeler <cz...@apache.org>:
>> 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
>>
>>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Support for OSGi
Posted by nicolas de loof <ni...@apache.org>.
Could such support be added using maven-osgi ?
(https://svn.apache.org/repos/asf/maven/shared/trunk/maven-osgi/)
I've never used it myself, but from what I've read on osgi, the bundle
meta-datas could be created based on the POM (for modules depdendencies,
version, etc..) Just the public API needs to be set in any way.
The felix wrappers (http://svn.apache.org/repos/asf/felix/trunk/commons/)
use a custom bundle packaging based on felix maven-bundle-plugin. How to
this tooling overlap with maven-osgi ?
Latest question, why not just provide the required MANIFEST entries (or
plugin configuration) as patch ? All the required work seems to have been
done on felix side !
Nico.
2007/12/19, Carsten Ziegeler <cz...@apache.org>:
>
> 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
>
>