Hi, A neat possibility for this scenario is to use the existing wrap: protocol, but providing a specific set of BND instructions for the conversion. See [1] for some clear steps on how to use this technique.
The idea is that you provide the wrap: protocol not only the URL of the JAR to wrap, but also the location of the BND instruction file to customise the conversion to an OSGi bundle. You can maintain the BND instructions file in either the filesystem or in the maven repo too. This is the best of both worlds IMHO, as you don't need to go as far as using maven-bundle-plugin, nor are you stuck with the standard set of BND conversions that the wrap protocol applies. By applying this in your scenario, your JAR can keep evolving in an OSGi-agnostic environment, and predictably all you'll ever need to do is to make small adjustments to the initial BND instructions file in specific situations, i.e. When new versions of the JAR mandate an adaptation on the OSGi level (e.g. Exporting/importing new packages, versions, etc.). [1] http://davidvaleri.wordpress.com/2010/08/13/combining-karaf-features-pax-ur l-and-maven-to-deploy-a-plain-jar-as-an-osgi-bundle/. Regards, Raúl. On 14/11/2011 23:51, "David Jencks" <[email protected]> wrote: > >On Nov 14, 2011, at 1:29 PM, mikevan wrote: > >> >> >> David, >> >> >> >> This came up today for me. In my application, we use 16 .jar files >>that are not OSGI-friendly. In our features.xml files we are using the >>wrap:mvn urn to deploy these into karaf. Normally, we would create >>wrapped versions of these files using bnd, prepending "osgi" to the >>version number of the bundle for official product releases. >>Unfortunately, this is not sustainable for releases as we would need to >>re-wrap all of these .jar files if they are updated. Karaf should have >>a way to easily deploy non-OSGi .jar files. This purpose was filled by >>the wrap:mvn urn, but that also appears to be buggy. > >I'm going to argue with you. I don't think it's significantly more work >to maintain 16 maven projects that repackage jar files than it is to >maintain the 16 jar versions. Furthermore it provides a clear >unambiguous single source for what you did to generate the osgi manifest >and pushes the time it takes to run bnd on the jar into your build >instead of each time you deploy the jar on your osgi framework. > >> >> >> >> In my usage, I get the following exception when using wrap:mvn: >> >> <date> | WARN | Thread-# | BndUtils | ps4j.pax.swissbox.bnd.BndUtils$1 >><#> | # - org.ops4j.pax.url.wrap - 1.2.5 | Bundle cannot be generated. >> >> >> >> If the answer is that we need to wrap all of the unfriendly .jar files >>manually, this is a strike against OSGi. Are there other options >>available other than wrap:mvn? > >I don't know why wrap isn't working for this jar, I'd investigate and try >to figure out. It's likely to be the same problem no matter when the >conversion takes place, e.g. using maven-bundle-plugin in a separate >project. IIUC you can, if you work hard enough, specify complete bnd >configuration in the wrap url. I still think putting that configuration >into your build system makes more sense. > >If you're going to start with a non-bundle and deploy it into osgi, you >have to turn it into a bundle somehow. I think the most sensible thing >is to create a new artifact under maven control that you can use >anywhere. The wrap url handler does the same thing but at the last >possible moment, so you can be assured that bnd will be run as many times >as possible and you get the greatest opportunity for different results >each time. I'm suggesting that if you try to put a non-bundle into a >kar, we ought to run bnd once then instead of each time you deploy the >kar. > >thanks >david jencks >> >> >> >> >> >> ----- Original Message ----- >> >> >> From: "David Jencks [via Karaf]" >><[email protected]> >> To: "mikevan" <[email protected]> >> Sent: Monday, November 14, 2011 4:18:26 PM >> Subject: Re: Building KARs with karaf-maven-plugin 3.0.0-SNAPSHOT >> >> My personal opinion is that support for wrap urls is not a good idea >>anywhere. >> >> If we are going to do something to support using non-bundles as input >>to the kar contents I would think the way to do it is to require a >>complete enough wrap url to do a good job, and turn the jar into a >>bundle on the way into the kar. >> >> thanks >> david jencks >> >> On Nov 14, 2011, at 1:06 PM, mgardiner wrote: >> >> >>> Hi All, >>> >>> I am trying to use the karaf-maven-plugin 3.0.0-SNAPSHOT to generate a >>> features.xml and bundle it into the KAR but I am seeing an issue for >>> non-bundles. It does generate a feature xml file but what I am >>>noticing is >>> that none of the urls for non-bundles in the generated feature xml get >>> prefixed with a "wrap:" so when I deploy the kar to the deploy >>>directory in >>> Karaf 2.2.4 it throws a BundleException. >>> >>> org.osgi.framework.BundleException: Jar is not a bundle, no >>> Bundle-SymbolicName >>> >>> As a work-around I explicity put "wrap:" prefix in front of the uri >>>for the >>> non-bundles in an input feature xml and then I end up with two bundles >>>being >>> defined in the output feature.xml. I can exclude the artifact in my >>>pom.xml >>> in the dependency list but this does not always work for transient >>> dependencies. >>> >>> So how do I >>> >>> 1) Use the karaf-maven-plugin but not overwrite my manually created >>> feature.xml to build a KAR >>> or >>> 2) Use the karaf-maven-plugin to build a KAR that automatically >>>generates >>> the feature xml with correctly prefixed uris that include the "wrap:" >>>prefix >>> for non-bundles >>> >>> Thanks. >>> >>> -Mike- >>> >>> -- >>> View this message in context: >>>http://karaf.922171.n3.nabble.com/Building-KARs-with-karaf-maven-plugin- >>>3-0-0-SNAPSHOT-tp3507984p3507984.html >>> Sent from the Karaf - User mailing list archive at Nabble.com. >> >> >> >> >> >> If you reply to this email, your message will be added to the >>discussion below: >>http://karaf.922171.n3.nabble.com/Building-KARs-with-karaf-maven-plugin-3 >>-0-0-SNAPSHOT-tp3507984p3508018.html >> To start a new topic under Karaf - User, email >>[email protected] >> To unsubscribe from Karaf - User, click here . >> NAML >> >> ----- >> Mike Van (All links open in new tabs) >> Committer - Kalumet >> >> Atraxia Technologies >> >> NCI Inc >> >> Mike Van's Open Source Technologies Blog >> -- >> View this message in context: >>http://karaf.922171.n3.nabble.com/Building-KARs-with-karaf-maven-plugin-3 >>-0-0-SNAPSHOT-tp3507984p3508043.html >> Sent from the Karaf - User mailing list archive at Nabble.com. >
