Support for OSGi

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Support for OSGi

Carsten Ziegeler
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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Tom Schindl-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

nicolas de loof
In reply to this post by Carsten Ziegeler
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 <[hidden email]>:

>
> 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
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Carsten Ziegeler
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 <[hidden email]>:
>> 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
>> [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


--
Carsten Ziegeler
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

simon.kitching@chello.at
In reply to this post by Carsten Ziegeler

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Niall Pemberton
In reply to this post by Carsten Ziegeler
On Dec 19, 2007 2:38 PM, Carsten Ziegeler <[hidden email]> 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
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Torsten Curdt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Stephen Colebourne
In reply to this post by Carsten Ziegeler
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Stuart McCulloch-3
In reply to this post by Niall Pemberton
On 20/12/2007, Niall Pemberton <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Carsten Ziegeler
In reply to this post by Torsten Curdt
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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

nicolas de loof
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 <[hidden email]>:

>
> 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
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Carsten Ziegeler
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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Carsten Ziegeler
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
[hidden email]

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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Carlos Sanchez-4
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 <[hidden email]> 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
> [hidden email]
>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Niclas Hedhman
In reply to this post by simon.kitching@chello.at
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Alan D. Cabrera

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Niclas Hedhman
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Henri Yandell
In reply to this post by Carsten Ziegeler
On Dec 28, 2007 4:35 AM, Carsten Ziegeler <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Carsten Ziegeler
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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for OSGi

Niall Pemberton
In reply to this post by Carsten Ziegeler
On Dec 28, 2007 12:35 PM, Carsten Ziegeler <[hidden email]> 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
> [hidden email]
>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123