I have an osgi-bundle which is created by using the maven-bundle-plugin:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
</instructions>
</configuration>
</plugin>
The bundle is installed via the maven-sling-plugin.
I have a fasterxml.jackson dependency which exists as an osgi-bundle in my .m2 repo and acts as a dependency in my project.
How can I make maven deploy this dependency as an osgi-bundle as well?
At the moment I have to install it manually in my osgi-container.
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>2.2.2</version>
</dependency>
EDIT:
Simplification:
How do I make maven realize that an osgi-bundle which I refer to as a dependency in my pom.xml shall be installed in the osgi-container along with the bundles that depend upon it?
You'll probably find its best to package your bundle as part of your application along with the /content, /apps portions of your application in the /apps/myapp/install folder will cause the libraries to be installed as bundles by the jcr installer provider.
There are a couple of ways of automating packaging/deployment of applications using maven described in these articles:
http://www.cognifide.com/blogs/cq/maven-plugin-automating-deployments-of-crx-cq-applications/
http://mkalugin-cq.blogspot.co.uk/2012/11/how-to-use-maven-project-to-create.html
http://labs.sixdimensions.com/blog/dklco/2012-05-03/introducing-cq-deploy-maven-plugin-deploying-cq-projects
http://dev.day.com/docs/en/cq/current/core/how_to/how_to_use_the_vlttool/vlt-mavenplugin.html
Alternatively, you could just use the CRXDE to place the bundles and then CRX Package Manager to test the approach, them move on to automated packaging later.
If you don't want to repackage the two OSGI bundles, you can use the sling maven plugin to install the jackson bundle directly
mvn org.apache.sling:maven-sling-plugin:install-file -Dsling.file=jackson-databind-2.2.2.jar
Related
There are lots of tutorials, which shows how to cope with dependencies of the OSGi project and how should they be converted to the bundle. After more than one day research, I have still not found how to deal with the dependencies with provided scope.
Let me give an example. I am currently using Dropbox (dropbox-core-sdk 3.0) and it has two dependencies (com.google.android and javax.servlet) with provided scope. When I use the techniques such as maven-bundle-plugin or bnd, it only downloads the artifacts and its transitive dependencies. However, I need also provided dependencies in order to be able to import my project to the OSGi container.
I am using maven-bundle-plugin and my pom.xml looks like:
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.artifactId};singleton:=true</Bundle-SymbolicName>
<Bundle-Version>${project.version}</Bundle-Version>
<Export-Package>*</Export-Package>
<Embed-Transitive>true</Embed-Transitive>
<Embed-Dependency>*</Embed-Dependency>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
even if Embed-Dependency says include everything, only the dependencies + transitive dependencies are in the jar. However, I want the provided-scoped jars are also in the jar.
Is there any way to download dependencies with provided scope. If not, how to deal with this situation?
I would have to defer to the Maven BND experts out there, but I don't think you can include provided dependencies through a Maven build. Since it is unlikely you will be using the Android components outside of your bundle, couldn't you just manually download the needed Jars and place them in your bundle (Bundle-Classpath)?
I think you can specify the scopes of the dependencies you want to embed. Be careful though that some dependencies like the OSGi spec jars should never be deployed.
In general you may only embed dependencies that are hidden inside the bundle. Any packages that are needed to talk to other bundles should better not deployed.
For example the servlet api is typically provided by the httpservice bundle you use.
Try this option:
<Embed-Dependency>*;scope=compile|provided</Embed-Dependency>
For development I run application using jetty through maven (jetty-maven-plugin) and for all other deployments I use tomcat,
I want jetty web-socket(javax-websocket-server-impl) libs added to the classpath on if I run my app using jetty maven plugin, in tomcat these are inbuilt so I need not tell maven to grab these libs.
so to restrict these libs only for jetty maven plugin I added these libs inside
jetty-maven-plugin
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty.version}</version>
<configuration>
<webAppConfig>
<contextPath>/myproject</contextPath>
</webAppConfig>
</configuration>
<dependencies>
<dependency>
<groupId>org.eclipse.jetty.websocket</groupId>
<artifactId>javax-websocket-server-impl</artifactId>
<version>9.1.0.v20131115</version>
</dependency>
</dependencies>
</plugin>
this should add the jetty websocket libs to the classpath only if I run the plugin, but Its not,and I keep getting class not found, and if I add this to main dependencies in the pom it works, but i cannot do this because I dont want jetty libs in my deployment file when deployed in tomcat, please correct me, tell me how to restrict these libs only to the execution of this plugin.
The dependency will only be available for the plugins execution, not for the application. From the pom plugin documentation:
dependencies: Dependencies are seen a lot within the POM, and are an element under all plugins element blocks. The dependencies have the same structure and function as under that base build. The major difference in this case is that instead of applying as dependencies of the project, they now apply as dependencies of the plugin that they are under. The power of this is to alter the dependency list of a plugin, perhaps by removing an unused runtime dependency via exclusions, or by altering the version of a required dpendency.
You can use profiles instead, to add the dependency to the class path dependencies when running on the development machine.
I'm having an issue with an OSGi bundle project as follows:
I have classes that require the use of JDOM. I currently have the project working fine when I deploy JDOM as a separate bundle. That bundle exports the following packages:
org.jdom,version=1.0.0
org.jdom.adapters,version=1.0.0
org.jdom.filter,version=1.0.0
org.jdom.input,version=1.0.0
org.jdom.output,version=1.0.0
org.jdom.transform,version=1.0.0
org.jdom.xpath,version=1.0.0
Now I want to change the project such that I include JDOM as an Embed-dependency. To do that I add the dependency to my pom files and set the following in the maven-bundle-plugin configuration:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>com.qnx.aem.cloudsite-bundle</Bundle-SymbolicName>
<Embed-Transitive>true</Embed-Transitive>
<Embed-Dependency>jdom</Embed-Dependency>
</instructions>
</configuration>
</plugin>
After this when I look at our projects bundle manifest I see a bunch of new Import Packages requiring dependencies of the JDOM jar: jaxen, xerces, etc.
How on earth did the previously deployed OSGi bundle of JDOM resolve these same dependencies? They were never listed in the bundles Import Packages? Furthermore if I try to include these as dependencies of the project and embed them it just compounds the problem. Help!
The bundle that you use imports those packages with "resolution:=optional". Due to this reason, the original bundle could have been resolved without having the dependencies in the OSGi container.
I guess that When you embedded the dependency, maven-bundle-plugin analyzed the bytecode of the embedded dependency instead of the MANIFEST header. The packages are imported without the "resolution:=optional" directive. You can specify it again in the configuration of maven-bundle-plugin like this:
<Import-Package>
org.jaxen.*;resolution:=optional,
*
</Import-Package>
Question is: Why do you want to embed a jar that is already a working OSGi bundle? It is better to use it as it is.
I'm an OSGI newb.
I can really use any guidance I can get regarding IntelliJ IDEA / OSGI / Maven / Sling.
So the actual Felix plugin dies when I load it. Apparently it hasn't been maintained and is no longer compatible with the latest release by which I mean IntelliJ IDEA 13.
So I've configured the framework to felix-framework-4.2.1, and that seems to work fine. My greatest concern is that if I apply the OSGI facet to a bundle, the settings seem to indicate that it will change the bundle. Since we have this set up in Maven, I don't think we want this. The source of the facet seems to be the Osmorc plugin. When I used it before, there were complaints about some packages in maven that weren't OSGI enabled and the IDE wanted to point to a special Spring repository for OSGI enabled jar dependencies.
Since we are doing this in Maven, should I even bother with Osmorc? Is there a better way to manage OSGI in IntelliJ IDEA? It is handy knowing which packages are OSGI enabled but an error for that? Really? Specifically I am referring to "The package is not exported by the bundle dependencies" showing up on imports and annotations.
My personal observation with Intellij IDEA 13 is that the OSGI project inspector is slightly more aggressive when it comes to profiling your classes that utilize non-osgi exported classes. That being said, a way around this is by adjusting the inspector severity level. This enables you to use the same OSGI-based approach you were using in Intellij IDEA 12.
To do this, go into your project settings (on Mac: Command+,) and then navigate to the following node:
Inspections --> OSGI --> Package accessibility
Once selected, you'll be able to change the severity level from error to warning.
Performing this change is requisite on a few changes in your pom.xml:
<dependencies>
.
.
<dependency>
<groupId>com.pkg.name</groupId>
<artifactId>some-non-osgi-artifact</artifactId>
<version>0.1-EXAMPLE</version>
</dependency>
</dependencies>
<build>
<plugins>
.
.
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>${maven-bundle-plugin.version}</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<Bundle-Version>${project.version}</Bundle-Version>
<Export-Package>
you.know.what.goes.here
</Export-Package>
<Private-Package>you.know.what.goes.here</Private-Package>
<Import-Package>
*
</Import-Package>
<Embed-Dependency>some-non-osgi-artifact;scope=compile|runtime;inline=false</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
<Embed-StripGroup>true</Embed-StripGroup>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
Hope this helps,
Ajay
I think your best bet currently is to use the maven bundle plugin to manage your imports and exports. This means intellij will simply see your bundles as maven projects. Still the correct jars should result. I handle OSGi bundles the same way in eclipse and it works fine.
I also read on the OSGi dev mailing list that there is a bndtools for intellij planned but this will for sure take a while.
I came across this question when trying to share the Struts packages among multiple bundles inside an OSGi container. I wanted to avoid both duplicating dependencies inside the bundles and introducing a new dependency between them (by having one bundle export its internal dependencies for the other to share).
It turns out the answer is very easy if you happen to use Maven, and if you aren't, you can still use the Maven solution to learn how to create the same result with some other mechanism.
I found this approach useful multiple times during my project, so I'll post an example here.
An additional path for those not so keen on maven, unable to port, or perfectly happy with ant/ivy
I've found the that easiest way to accomplish the stated task is to turn the non-OSGi library into an OSGi library by letting the manifest export every package and add on some approriate symbolic names / versions. I've been able to do this VERY easily with bnd via ant tasks (or even direct command line invocation). There are also repositories which contain "osgi-ified" version of many popular libraries. Some libraries (joda-time) are already shipping with correct OSGi manifests.
Using Maven, it is very easy to create an OSGi bundle from any library. However, I think the same result can be created with other mechanisms, too. The Maven solution helped me understand how it works.
Creating the bundle is done by creating a project which has the library as a dependency and then packaging the project using the maven-bundle-plugin from the Apache Felix project and specifying the library packages with the Export-Package instruction. I used this to share Google Protocol Buffers between bundles inside an OSGi container:
<?xml version="1.0" encoding="UTF-8" ?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example.lib</groupId>
<artifactId>protobuf-dist</artifactId>
<version>2.1.0</version>
<name>Google Protocol Buffers OSGi Distribution</name>
<packaging>bundle</packaging>
<dependencies>
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>2.1.0</version>
<scope>compile</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>com.google.protobuf</Export-Package>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
</project>
If you want all transitive dependencies rolled into the bundle, too, use the bundleall goal of the plugin.
The plugin recognizes and honours existing OSGi manifests in the dependency.
You can also use the bundle plugin to just create the manifest and tell the jar packaging plugin (or the jar-with-dependencies builtin assembly) to use that manifest via the archive section. The plugin's page linked above shows how to do that.