You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Nick Campion <nc...@linux.vnet.ibm.com> on 2008/07/16 18:23:30 UTC
Bundle Dependency Problem
I've been struggling with a problem for a few days now. I am trying to
build a bundle using maven. Although I'm new to maven, I think the
problem seems legitimate.
I'll explain the problem with a contrived example. This bundle (we'll
call it bundle A) is dependent on a bundles provided by the OSGi
environment. This bundle is constructed in a fashion that is causing me
significant trouble.
Bundle B has the following contents:
./META-INF/MANIFEST.MF
./classes/func1.jar
./classes/func2.jar
...etc....
In the manifest file, there is a Bundle-ClassPath entry that looks like
this:
Bundle-ClassPath: classes/, ,classes/func1.jar, classes/func2.jar
The manifest also has an Export-Package section that looks somewhat like
this:
Export-Package: com.nick.func1, com.nick.func2
Thus, the bundle is exporting the functionality of the jars out through
a bundle as com.nick.func1 resides in func1.jar. Bundle B is not build
by my team and is not created using Maven. It is put into our
repository automatically by the eclipse:to-maven goal.
Now, my bundle A is dependent on package com.nick.func1. Since this is
exported by bundle B, I add bundle B to my maven pom.xml as a provided
dependency. I can see that bundle B is added to the classpath call
during the maven compile by adding the debug parameter, but the
compilation of bundle A fails saying package com.nick.func1 cannot be
found. I can only imagine this is because the class loader is not
considering the Bundle-ClassPath of bundle B for possible inclusion into
the classpath for compilation of A.
The eclipse workbench seems to be able to handle this situation, but
we'd really like to use Maven to do the compile. Has anyone seen this
problem before that can suggest a workaround?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle Dependency Problem
Posted by Nick Campion <nc...@linux.vnet.ibm.com>.
Stuart McCulloch wrote:
> 2008/7/17 Nick Campion <nc...@linux.vnet.ibm.com>:
>
>
>> I've been struggling with a problem for a few days now. I am trying to
>> build a bundle using maven. Although I'm new to maven, I think the problem
>> seems legitimate.
>>
>> I'll explain the problem with a contrived example. This bundle (we'll call
>> it bundle A) is dependent on a bundles provided by the OSGi environment.
>> This bundle is constructed in a fashion that is causing me significant
>> trouble.
>>
>> Bundle B has the following contents:
>> ./META-INF/MANIFEST.MF
>> ./classes/func1.jar
>> ./classes/func2.jar
>> ...etc....
>>
>> In the manifest file, there is a Bundle-ClassPath entry that looks like
>> this:
>>
>> Bundle-ClassPath: classes/, ,classes/func1.jar, classes/func2.jar
>>
>> The manifest also has an Export-Package section that looks somewhat like
>> this:
>>
>> Export-Package: com.nick.func1, com.nick.func2
>>
>> Thus, the bundle is exporting the functionality of the jars out through a
>> bundle as com.nick.func1 resides in func1.jar. Bundle B is not build by my
>> team and is not created using Maven. It is put into our repository
>> automatically by the eclipse:to-maven goal.
>>
>> Now, my bundle A is dependent on package com.nick.func1. Since this is
>> exported by bundle B, I add bundle B to my maven pom.xml as a provided
>> dependency. I can see that bundle B is added to the classpath call during
>> the maven compile by adding the debug parameter, but the compilation of
>> bundle A fails saying package com.nick.func1 cannot be found. I can only
>> imagine this is because the class loader is not considering the
>> Bundle-ClassPath of bundle B for possible inclusion into the classpath for
>> compilation of A.
>>
>> The eclipse workbench seems to be able to handle this situation, but we'd
>> really like to use Maven to do the compile. Has anyone seen this problem
>> before that can suggest a workaround?
>>
>>
>
> by default Maven uses javac for compilation - and javac does not support
> embedded jars
>
> you could try switching to the Eclipse compiler:
>
> <pluginManagement>
> <plugins>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <configuration>
> <compilerId>eclipse</compilerId>
> </configuration>
> <dependencies>
> <dependency>
> <groupId>org.codehaus.plexus</groupId>
> <artifactId>plexus-compiler-eclipse</artifactId>
> <version>1.5.1</version>
> </dependency>
> </dependencies>
> </plugin>
> </plugins>
> </pluginManagement>
>
> but I'm not sure if that supports embedded jars either - the PDT tooling in
> Eclipse
> is grafted on top of JDT and I think there's some extra magic to support
> this that
> isn't in the base tooling (but I may be wrong)
>
We tried this without success. The plugin seems to be out of date or
incompatible with what we currently have setup.
> if that all fails then you could consider adding the maven-pax-plugin to
> your build:
>
> <plugins>
> <plugin>
> <groupId>org.ops4j</groupId>
> <artifactId>maven-pax-plugin</artifactId>
> <version>1.3</version>
> <!--
> | enable improved OSGi compilation support for the bundle
> life-cycle.
> | to switch back to the standard bundle life-cycle, move this
> setting
> | down to the maven-bundle-plugin section
> -->
> <extensions>true</extensions>
> </plugin>
> </plugins>
>
> you'll also need to remove the <extensions>true</extensions> from the
> bundleplugin
> because the maven-pax-plugin provides a customized "bundle" lifecycle with
> modified
> compilation stages that unpack embedded jars automatically so javac can find
> them
> (you should see [pax:compile] appear for the compile phase)
>
This worked great. The pax plugin seemed to do a lot of the dirty work
for us and got us past this blocking issue. Thanks for your quick
response and recommendation. Hopefully this will help others too!
Nick
> FYI, this plugin is part of Pax-Construct (
> http://www.ops4j.org/projects/pax/construct)
> but can be used in any Maven OSGi project, not just projects created by
> these tools.
>
> HTH
>
> ---------------------------------------------------------------------
>
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle Dependency Problem
Posted by Stuart McCulloch <st...@jayway.net>.
2008/7/17 Nick Campion <nc...@linux.vnet.ibm.com>:
> I've been struggling with a problem for a few days now. I am trying to
> build a bundle using maven. Although I'm new to maven, I think the problem
> seems legitimate.
>
> I'll explain the problem with a contrived example. This bundle (we'll call
> it bundle A) is dependent on a bundles provided by the OSGi environment.
> This bundle is constructed in a fashion that is causing me significant
> trouble.
>
> Bundle B has the following contents:
> ./META-INF/MANIFEST.MF
> ./classes/func1.jar
> ./classes/func2.jar
> ...etc....
>
> In the manifest file, there is a Bundle-ClassPath entry that looks like
> this:
>
> Bundle-ClassPath: classes/, ,classes/func1.jar, classes/func2.jar
>
> The manifest also has an Export-Package section that looks somewhat like
> this:
>
> Export-Package: com.nick.func1, com.nick.func2
>
> Thus, the bundle is exporting the functionality of the jars out through a
> bundle as com.nick.func1 resides in func1.jar. Bundle B is not build by my
> team and is not created using Maven. It is put into our repository
> automatically by the eclipse:to-maven goal.
>
> Now, my bundle A is dependent on package com.nick.func1. Since this is
> exported by bundle B, I add bundle B to my maven pom.xml as a provided
> dependency. I can see that bundle B is added to the classpath call during
> the maven compile by adding the debug parameter, but the compilation of
> bundle A fails saying package com.nick.func1 cannot be found. I can only
> imagine this is because the class loader is not considering the
> Bundle-ClassPath of bundle B for possible inclusion into the classpath for
> compilation of A.
>
> The eclipse workbench seems to be able to handle this situation, but we'd
> really like to use Maven to do the compile. Has anyone seen this problem
> before that can suggest a workaround?
>
by default Maven uses javac for compilation - and javac does not support
embedded jars
you could try switching to the Eclipse compiler:
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerId>eclipse</compilerId>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-compiler-eclipse</artifactId>
<version>1.5.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>
but I'm not sure if that supports embedded jars either - the PDT tooling in
Eclipse
is grafted on top of JDT and I think there's some extra magic to support
this that
isn't in the base tooling (but I may be wrong)
if that all fails then you could consider adding the maven-pax-plugin to
your build:
<plugins>
<plugin>
<groupId>org.ops4j</groupId>
<artifactId>maven-pax-plugin</artifactId>
<version>1.3</version>
<!--
| enable improved OSGi compilation support for the bundle
life-cycle.
| to switch back to the standard bundle life-cycle, move this
setting
| down to the maven-bundle-plugin section
-->
<extensions>true</extensions>
</plugin>
</plugins>
you'll also need to remove the <extensions>true</extensions> from the
bundleplugin
because the maven-pax-plugin provides a customized "bundle" lifecycle with
modified
compilation stages that unpack embedded jars automatically so javac can find
them
(you should see [pax:compile] appear for the compile phase)
FYI, this plugin is part of Pax-Construct (
http://www.ops4j.org/projects/pax/construct)
but can be used in any Maven OSGi project, not just projects created by
these tools.
HTH
---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart