Hi

I have used that instruction in the past. By now I find it easier to
configure the bundle plugin including a file "osgi.bnd"
which lives in the bundle root directory alongside the pom file.

The bundle-plugin would be configured as:

<plugin>
  <groupId>org.apache.felix</groupId>
  <artifactId>maven-bundle-plugin</artifactId>
  <version>2.3.7</version>
  <extensions>true</extensions>
  <executions>
    <execution>
      <id>manifest</id>
      <phase>process-classes</phase>
      <goals>
      <goal>manifest</goal>
     </goals>
    </execution>
  </executions>
  <configuration>
    <supportedProjectTypes>
    <supportedProjectType>jar</supportedProjectType>
    <supportedProjectType>bundle</supportedProjectType>
    <supportedProjectType>war</supportedProjectType>
  </supportedProjectTypes>
  <instructions>
    <_include>-osgi.bnd</_include>
  </instructions>
          </configuration>
        </plugin>


Note that this configuration also allows me to OSGIFY wars and jars if I
need it. 

A typical osgi.bnd file would look like:

Bundle-Version:\
  ${project.version}

Bundle-SymbolicName:\
  ${bundle.symbolicName}; singleton:=true

Export-Package: ${bundle.namespace}

Import-Package: \
  *

Private-Package: \
  ${bundle.namespace}.internal


The variables ${bundle.namespace} and ${bundle.symbolicName} always
resolve to my artifactId, which is in my bundles always
${project.groupId} + "." + uniqueidentifier.


Having this kind of structure kind of gives you a natural order of
packages and exports.

Have fun
Andreas







Am 7/16/13(29) 9:48 AM schrieb "Cristiano Costantini" unter
<cristiano.costant...@gmail.com>:

>Thank you Andreas for the hints on how to layout the packages.
>
>(I'm just studying how to make it work and not yet started to refine the
>code style,
>I will surely take care of your recommendation.)
>
>Could you confirm right way to export a resource in OSGi is to use the
><Export-Package> instruction?
>
>Thank you,
>
>Cristiano
>
>
>
>
>
>2013/7/16 Andreas Gies <andr...@wayofquality.de>
>
>> Elaborating on Claus' answer. The XSLT processor tries to resolve the
>>XSLT
>> "test/test.xsl".
>> In OSGI words, it has to resolve a package "test" which contains the
>> resource test.xsl.
>>
>> Though exporting the package "test" would probably work, I would
>>strongly
>> recommend to have
>> better qualified package names to avoid name clashes in exports.
>> Especially generically named
>> packages like "test" or "sample" may very well lead into a world of pain
>> (been there).
>>
>> Once you go about exporting packages, think what you want / need to
>>expose
>> to other bundles.
>> I always keep my internal stuff in a package ending in ".internal" and
>> have configured my builds
>> not to export something that matches this pattern.
>>
>> Good luck
>> Andreas
>>
>>
>>
>>
>>
>>
>>
>> Am 7/16/13(29) 9:29 AM schrieb "Claus Ibsen" unter
>><claus.ib...@gmail.com
>> >:
>>
>> >If the xsl file is in the classpath of your own bundle, then you need
>> >to export this package. Looks like you put it in a test package.
>> >
>> >On Tue, Jul 16, 2013 at 9:27 AM, Cristiano Costantini
>> ><cristiano.costant...@gmail.com> wrote:
>> >> I must update my previous question:
>> >> velocity in facts works fine, it is just xslt which causing issues!
>> >>
>> >> My test route is in fact:
>> >> <route id="testRoute">
>> >> <from uri="timer://myTimer?period=5000" />
>> >> <setBody>
>> >> <constant>Foo</constant>
>> >> </setBody>
>> >> <to uri="velocity://test/test.vm" />
>> >> <to uri="xslt://test/test.xsl" />
>> >> <to uri="log:foo" />
>> >> </route>
>> >>
>> >> the velocity: endpoint works, it is the xslt: which fail...
>> >> I'm able to run it if I use the full path for just the XSL file:
>> >>
>> >> <route id="testRoute">
>> >> <from uri="timer://myTimer?period=5000" />
>> >> <setBody>
>> >> <constant>Foo</constant>
>> >> </setBody>
>> >> <to uri="velocity://test/test.vm" />
>> >> <to
>> >>
>> 
>>>>uri="xslt://file:///C:/dev/Sandbox/osgi-deploy-test/src/main/resources/
>>>>te
>> >>st/test.xsl"
>> >> />
>> >> <to uri="log:foo" />
>> >> </route>
>> >>
>> >> Anyone has any suggestion on how to address this problem?
>> >>
>> >> My only suspect is that when I run from eclipse a simple java class
>> >>with a
>> >> main(String[] args) method where I start a
>> >>ConfigurableApplicationContext)
>> >> where it works, and when I deploy on OSGi, I'm actually using two
>> >>different
>> >> XSLT processors, but I'm not sure how to debug it...
>> >>
>> >> thank you again,
>> >>
>> >> Cristiano
>> >>
>> >>
>> >>
>> >>
>> >> 2013/7/16 Cristiano Costantini <cristiano.costant...@gmail.com>
>> >>
>> >>> Hello,
>> >>>
>> >>> I just tried to deploy my camel routes into an OSGi environment
>> >>> (ServiceMix).
>> >>>
>> >>> I've made a simple maven project with just resources (the beans.xml,
>> >>>.xsl
>> >>> and .vm files),
>> >>> however the XSLT and Velocity endpoints cannot find the associated
>> >>>files (
>> >>> with exception "Failed to resolve endpoint: xslt://testTransform.xsl
>> >>>due
>> >>> to: java.io.FileNotFoundException: Cannot find resource in classpath
>> >>>for
>> >>> URI: testTransform.xsl").
>> >>>
>> >>> If I run the route locally (in a simple java console application)
>> >>> everything works fine.
>> >>>
>> >>> Anyone has experience on this type of deployment and can give me
>>some
>> >>>hint?
>> >>>
>> >>> Thank you,
>> >>> Cristiano
>> >>>
>> >
>> >
>> >
>> >--
>> >Claus Ibsen
>> >-----------------
>> >Red Hat, Inc.
>> >Email: cib...@redhat.com
>> >Twitter: davsclaus
>> >Blog: http://davsclaus.com
>> >Author of Camel in Action: http://www.manning.com/ibsen
>>
>>
>>


Reply via email to