You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Rajini Sivaram <ra...@googlemail.com> on 2007/11/12 12:08:56 UTC

maven-bundle-plugin : bundleall

Hello,

I am trying to generate OSGi bundles corresponding to a Apache Tuscany
distribution to run Tuscany under OSGi. Tuscany uses around 170 third party
libraries, and since I dont want to write 170 pom.xmls to convert each of
those into a bundle, the 'bundleall' goal provided by maven-bundle-plugin
looks like a very promising alternative. I have a couple of questions
related to 'bundleall' (I am using maven-bundle-plugin version
1.1.0-SNAPSHOT).

   1. Is it possible to get all the jars wrapped by bundleall to be added
   to an OBR repository? I tried
<obrRepository>myrepository.xml</obrRepository>,
   but the resulting repository file does not contain entries for the
   dependencies.
   2. Is it possible to specify that I want to wrap only the highest
   version of the jars (whichever version maven normally resolves to)? Many of
   the 3rd party libraries used by Tuscany have dependencies on other 3rd party
   libraries. When I run "bundleall", all of the versions of these dependencies
   get wrapped. Since Tuscany is normally run outside of OSGi, the Tuscany
   distribution uses maven to obtain a single version of each of the third
   party libraries. I would to like to insert an OSGi manifest into this single
   version, so that Tuscany can be optionally run inside OSGi.




Thank you...

Regards,

Rajini

Re: maven-bundle-plugin : bundleall

Posted by Rajini Sivaram <ra...@googlemail.com>.
Stuart/Richard,

Thank you for both your replies. I am using bindex at the moment, but I
prefer a maven plugin so that it can be easily used in the Tuscany build. I
will try out Pax-Construct.


Thank you...

Regards,

Rajini


On 11/12/07, Richard S. Hall <he...@ungoverned.org> wrote:
>
> Also, if you have a bunch of JAR files, you can use bindex from Peter
> Kriens to generate an OBR repository.
>
> -> richard
>
> Stuart McCulloch wrote:
> > On 12/11/2007, Rajini Sivaram <ra...@googlemail.com> wrote:
> >
> >> Hello,
> >>
> >> I am trying to generate OSGi bundles corresponding to a Apache Tuscany
> >> distribution to run Tuscany under OSGi. Tuscany uses around 170 third
> >> party
> >> libraries, and since I dont want to write 170 pom.xmls to convert each
> of
> >> those into a bundle, the 'bundleall' goal provided by
> maven-bundle-plugin
> >> looks like a very promising alternative. I have a couple of questions
> >> related to 'bundleall' (I am using maven-bundle-plugin version
> >> 1.1.0-SNAPSHOT).
> >>
> >>    1. Is it possible to get all the jars wrapped by bundleall to be
> added
> >>    to an OBR repository? I tried
> >> <obrRepository>myrepository.xml</obrRepository>,
> >>    but the resulting repository file does not contain entries for the
> >>    dependencies.
> >>
> >
> >
> > not at the moment - the bundleall goal simply creates a series of
> bundles
> > under the target directory
> > which aren't managed by maven (as they have no pom) and therefore don't
> get
> > installed in the local
> > maven repository or the OBR repository metadata
> >
> > it should be possible to attach the bundle files to the project
> dynamically,
> > so they could be installed
> > - you'd need to raise this as a new bundleplugin feature (
> > https://issues.apache.org/jira/browse/FELIX)
> >
> > however, please note that bundleall takes a mechanical approach to
> bundling
> > (export all contents)
> > which while ok for plain libraries is not enough for libraries that have
> > specific resource management
> > or thread life-cycles. For example a library may start a background
> thread
> > for certain API calls which
> > would need to be cleaned up when the bundle stopped, otherwise you
> wouldn't
> > be able to uninstall
> > or upgrade properly.
> >
> > for certain libraries (hopefully only a few of the 170!) you'd need to
> have
> > a Maven POM so you can
> > customize the manifest and maybe add a Bundle-Activator to manage
> > resource/thread life-cycles.
> >
> > btw, you might want to consider tools that build on and use the
> > bundleplugin, such as Pax-Construct:
> >
> >    http://www.ops4j.org/projects/pax/construct/index.html
> >
> > for example:
> >
> >    pax-wrap-jar -g commons-logging -a commons-logging -v 1.1
> >
> > would create a new POM to wrap the commons-logging library as a single
> > bundle containing just the
> > commons logging code (note the -g groupId option can be omitted as it's
> the
> > same as the artifactId)
> >
> > and:
> >
> >    pax-wrap-jar -a commons-logging -v 1.1 -- -DembedTransitive
> >
> > would also wrap commons-logging, but include the contents of its
> > dependencies in the same bundle.
> >
> > if you wanted each dependency as a separate bundle (with its own POM)
> you
> > would use:
> >
> >    pax-wrap-jar -a commons-logging -v 1.1 -- -DwrapTransitive
> >
> > (note - this also converts the old dependencies to be bundle
> dependencies in
> > the wrapper POM)
> > and if you wanted to mark any javax package and certain Sun packages as
> > optional, you'd use:
> >
> >    pax-wrap-jar -a commons-logging -v 1.1 -- -DwrapTransitive
> >       "-DimportPackage=javax.*|com.sun.jdmk.comm;resolution:=optional,*"
> >
> > the benefit of Pax-Construct (especially if created inside a project
> > generated from pax-create-project)
> > is that you can customize and manage the POMs over time, create Eclipse
> > project files, and do all the
> > things you'd do with a normal Maven project.
> >
> > see the site for all wrapping options - there are also commands to help
> > embed libraries inside bundles
> >
> >    2. Is it possible to specify that I want to wrap only the highest
> >
> >>    version of the jars (whichever version maven normally resolves to)?
> >> Many of
> >>    the 3rd party libraries used by Tuscany have dependencies on other
> 3rd
> >> party
> >>    libraries. When I run "bundleall", all of the versions of these
> >> dependencies
> >>    get wrapped. Since Tuscany is normally run outside of OSGi, the
> Tuscany
> >>    distribution uses maven to obtain a single version of each of the
> third
> >>    party libraries. I would to like to insert an OSGi manifest into
> this
> >> single
> >>    version, so that Tuscany can be optionally run inside OSGi.
> >>
> >
> >
> > this is possible with pax-wrap-jar - when using -DwrapTransitive it
> should
> > only wrap one version of a jar
> >
> > I believe it would be possible to add an option to bundleall that does
> > something similar - you'd need
> > to raise this as another feature request on JIRA (just so we can track
> it
> > separately from the first issue)
> >
> > Thank you...
> >
> >
> > np - hope this helps
> >
> > Regards,
> >
> >> Rajini
> >>
> >>
> >
> >
>

Re: maven-bundle-plugin : bundleall

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Also, if you have a bunch of JAR files, you can use bindex from Peter 
Kriens to generate an OBR repository.

-> richard

Stuart McCulloch wrote:
> On 12/11/2007, Rajini Sivaram <ra...@googlemail.com> wrote:
>   
>> Hello,
>>
>> I am trying to generate OSGi bundles corresponding to a Apache Tuscany
>> distribution to run Tuscany under OSGi. Tuscany uses around 170 third
>> party
>> libraries, and since I dont want to write 170 pom.xmls to convert each of
>> those into a bundle, the 'bundleall' goal provided by maven-bundle-plugin
>> looks like a very promising alternative. I have a couple of questions
>> related to 'bundleall' (I am using maven-bundle-plugin version
>> 1.1.0-SNAPSHOT).
>>
>>    1. Is it possible to get all the jars wrapped by bundleall to be added
>>    to an OBR repository? I tried
>> <obrRepository>myrepository.xml</obrRepository>,
>>    but the resulting repository file does not contain entries for the
>>    dependencies.
>>     
>
>
> not at the moment - the bundleall goal simply creates a series of bundles
> under the target directory
> which aren't managed by maven (as they have no pom) and therefore don't get
> installed in the local
> maven repository or the OBR repository metadata
>
> it should be possible to attach the bundle files to the project dynamically,
> so they could be installed
> - you'd need to raise this as a new bundleplugin feature (
> https://issues.apache.org/jira/browse/FELIX)
>
> however, please note that bundleall takes a mechanical approach to bundling
> (export all contents)
> which while ok for plain libraries is not enough for libraries that have
> specific resource management
> or thread life-cycles. For example a library may start a background thread
> for certain API calls which
> would need to be cleaned up when the bundle stopped, otherwise you wouldn't
> be able to uninstall
> or upgrade properly.
>
> for certain libraries (hopefully only a few of the 170!) you'd need to have
> a Maven POM so you can
> customize the manifest and maybe add a Bundle-Activator to manage
> resource/thread life-cycles.
>
> btw, you might want to consider tools that build on and use the
> bundleplugin, such as Pax-Construct:
>
>    http://www.ops4j.org/projects/pax/construct/index.html
>
> for example:
>
>    pax-wrap-jar -g commons-logging -a commons-logging -v 1.1
>
> would create a new POM to wrap the commons-logging library as a single
> bundle containing just the
> commons logging code (note the -g groupId option can be omitted as it's the
> same as the artifactId)
>
> and:
>
>    pax-wrap-jar -a commons-logging -v 1.1 -- -DembedTransitive
>
> would also wrap commons-logging, but include the contents of its
> dependencies in the same bundle.
>
> if you wanted each dependency as a separate bundle (with its own POM) you
> would use:
>
>    pax-wrap-jar -a commons-logging -v 1.1 -- -DwrapTransitive
>
> (note - this also converts the old dependencies to be bundle dependencies in
> the wrapper POM)
> and if you wanted to mark any javax package and certain Sun packages as
> optional, you'd use:
>
>    pax-wrap-jar -a commons-logging -v 1.1 -- -DwrapTransitive
>       "-DimportPackage=javax.*|com.sun.jdmk.comm;resolution:=optional,*"
>
> the benefit of Pax-Construct (especially if created inside a project
> generated from pax-create-project)
> is that you can customize and manage the POMs over time, create Eclipse
> project files, and do all the
> things you'd do with a normal Maven project.
>
> see the site for all wrapping options - there are also commands to help
> embed libraries inside bundles
>
>    2. Is it possible to specify that I want to wrap only the highest
>   
>>    version of the jars (whichever version maven normally resolves to)?
>> Many of
>>    the 3rd party libraries used by Tuscany have dependencies on other 3rd
>> party
>>    libraries. When I run "bundleall", all of the versions of these
>> dependencies
>>    get wrapped. Since Tuscany is normally run outside of OSGi, the Tuscany
>>    distribution uses maven to obtain a single version of each of the third
>>    party libraries. I would to like to insert an OSGi manifest into this
>> single
>>    version, so that Tuscany can be optionally run inside OSGi.
>>     
>
>
> this is possible with pax-wrap-jar - when using -DwrapTransitive it should
> only wrap one version of a jar
>
> I believe it would be possible to add an option to bundleall that does
> something similar - you'd need
> to raise this as another feature request on JIRA (just so we can track it
> separately from the first issue)
>
> Thank you...
>
>
> np - hope this helps
>
> Regards,
>   
>> Rajini
>>
>>     
>
>   

Re: maven-bundle-plugin : bundleall

Posted by Stuart McCulloch <st...@jayway.net>.
On 12/11/2007, Rajini Sivaram <ra...@googlemail.com> wrote:
>
> Hello,
>
> I am trying to generate OSGi bundles corresponding to a Apache Tuscany
> distribution to run Tuscany under OSGi. Tuscany uses around 170 third
> party
> libraries, and since I dont want to write 170 pom.xmls to convert each of
> those into a bundle, the 'bundleall' goal provided by maven-bundle-plugin
> looks like a very promising alternative. I have a couple of questions
> related to 'bundleall' (I am using maven-bundle-plugin version
> 1.1.0-SNAPSHOT).
>
>    1. Is it possible to get all the jars wrapped by bundleall to be added
>    to an OBR repository? I tried
> <obrRepository>myrepository.xml</obrRepository>,
>    but the resulting repository file does not contain entries for the
>    dependencies.


not at the moment - the bundleall goal simply creates a series of bundles
under the target directory
which aren't managed by maven (as they have no pom) and therefore don't get
installed in the local
maven repository or the OBR repository metadata

it should be possible to attach the bundle files to the project dynamically,
so they could be installed
- you'd need to raise this as a new bundleplugin feature (
https://issues.apache.org/jira/browse/FELIX)

however, please note that bundleall takes a mechanical approach to bundling
(export all contents)
which while ok for plain libraries is not enough for libraries that have
specific resource management
or thread life-cycles. For example a library may start a background thread
for certain API calls which
would need to be cleaned up when the bundle stopped, otherwise you wouldn't
be able to uninstall
or upgrade properly.

for certain libraries (hopefully only a few of the 170!) you'd need to have
a Maven POM so you can
customize the manifest and maybe add a Bundle-Activator to manage
resource/thread life-cycles.

btw, you might want to consider tools that build on and use the
bundleplugin, such as Pax-Construct:

   http://www.ops4j.org/projects/pax/construct/index.html

for example:

   pax-wrap-jar -g commons-logging -a commons-logging -v 1.1

would create a new POM to wrap the commons-logging library as a single
bundle containing just the
commons logging code (note the -g groupId option can be omitted as it's the
same as the artifactId)

and:

   pax-wrap-jar -a commons-logging -v 1.1 -- -DembedTransitive

would also wrap commons-logging, but include the contents of its
dependencies in the same bundle.

if you wanted each dependency as a separate bundle (with its own POM) you
would use:

   pax-wrap-jar -a commons-logging -v 1.1 -- -DwrapTransitive

(note - this also converts the old dependencies to be bundle dependencies in
the wrapper POM)
and if you wanted to mark any javax package and certain Sun packages as
optional, you'd use:

   pax-wrap-jar -a commons-logging -v 1.1 -- -DwrapTransitive
      "-DimportPackage=javax.*|com.sun.jdmk.comm;resolution:=optional,*"

the benefit of Pax-Construct (especially if created inside a project
generated from pax-create-project)
is that you can customize and manage the POMs over time, create Eclipse
project files, and do all the
things you'd do with a normal Maven project.

see the site for all wrapping options - there are also commands to help
embed libraries inside bundles

   2. Is it possible to specify that I want to wrap only the highest
>    version of the jars (whichever version maven normally resolves to)?
> Many of
>    the 3rd party libraries used by Tuscany have dependencies on other 3rd
> party
>    libraries. When I run "bundleall", all of the versions of these
> dependencies
>    get wrapped. Since Tuscany is normally run outside of OSGi, the Tuscany
>    distribution uses maven to obtain a single version of each of the third
>    party libraries. I would to like to insert an OSGi manifest into this
> single
>    version, so that Tuscany can be optionally run inside OSGi.


this is possible with pax-wrap-jar - when using -DwrapTransitive it should
only wrap one version of a jar

I believe it would be possible to add an option to bundleall that does
something similar - you'd need
to raise this as another feature request on JIRA (just so we can track it
separately from the first issue)

Thank you...


np - hope this helps

Regards,
>
> Rajini
>

-- 
Cheers, Stuart