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.
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>
Iam searching for a maven based solution to deploy apache sling bundle and content (including jsp/html, etc files) on my sling standalone server.
I stated this private project to learn about sightly and sling models without using AEM. It is my first only sling project.
Ive created a sling bundle and a sling content project from the specific archetypes. Ive stated working with the Eclipse Sling IDE tools, but iam used to IntelliJ and there is no plugin to deploy the contetent the same way. I think its possible to build and deploy a package with both (bundle and content) by using maven.
Hopefully someone of you have some instructions or ideas to solve this problem and make it more comfortable developing web projects with apache sling.
Cheers ;)
The maven-sling-plugin can install bundles in a Sling instance, and bundles can include initial content which is installed when they become active.
The slingbucks sample demonstrates this, if you build it as shown below it will be installed in the Sling instance running on port 8080 and its initial content (defined under src/main/resources/SLING-CONTENT as specified in that module's pom.xml) will be installed:
mvn clean install org.apache.sling:maven-sling-plugin:install -Dsling.url=http://localhost:8080/system/console
If you use the Sling parent pom you can also use the autoInstallBundle profile to do the same thing using the default URL that that pom defines:
mvn clean install -P autoInstallBundle
This project may help you https://github.com/auniverseaway/slick, see the pom.xml file there
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.0.1</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Sling-Initial-Content>
jcr_root/content;
overwriteProperties:=false;
overwrite:=false;
uninstall:=false;
path:=/content;
maven:mount:=false,
jcr_root/apps/slick;
overwrite:=true;
path:=/apps/slick;
maven:mount:=false,
jcr_root/apps/sling;
overwrite:=true;
path:=/apps/sling;
maven:mount:=false,
jcr_root/etc;
path:=/etc;
overwriteProperties:=false;
uninstall:=false,
jcr_root/i18n;
path:=/etc/i18n/net.zum.slick;
overwrite:=true;uninstall:=true
</Sling-Initial-Content>
<Bundle-Activator>net.zum.slick.internal.Activator</Bundle-Activator>
<Sling-Model-Packages>
net.zum.slick
</Sling-Model-Packages>
</instructions>
</configuration>
</plugin>
All in all the files inside the directories defined in <Sling-Initial-Content> space of the maven-bundle-plugin will be deployed with the bundle, correct?
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
I have put a few jars on my Bundle-Classpath. The line below shows the entry in my pom.xml, which uses the Felix plugin to create the manigest.mf for the bundle.
<Bundle-ClassPath>.,lib/com.springsource.org.h2-1.0.71.jar,lib/com.springsource.org.apache.lucene-2.3.2.jar,lib/com.springsource.org.apache.lucene.search-2.3.2.jar</Bundle-ClassPath>
These jars have classes which import packages, but from what I can see, they all have a MANIFEST.MF, which has it's own (accurate) list of Import-Package statements.
However, when I build my project (using Maven and the bundle plugin), it reports an error because it cannot resolve references to certain classes. Specifically the error is:
Unresolved references to [com.sun.tools.javac, javax.naming, javax.naming.spi, javax.servlet, javax.servlet.http, javax.sql, javax.transaction.xa]
All of these errors come from com.springsource.org.h2-1.0.71.jar and all these packages are imported in the manifest of that jar.
I am unable to understand:
Why is the Maven bundle plugin complaining, if these packages are already imported in the MANIFEST>MF of com.springsource.org.h2-1.0.71.jar
Why are the problems coming only from com.springsource.org.h2-1.0.71.jar ? I tried removing that specific jar and the build goes through fine, even though com.springsource.org.apache.lucene.search-2.3.2.jar also has several entries for Import-Package in it's MANIFEST.MF ?
About the second point, I did some investigation, and I feel like there is a pattern. All the imports which com.springsource.org.apache.lucene.search-2.3.2.jar specifies in it's manifest, are being satisfied by com.springsource.org.apache.lucene-2.3.2.jar, which is also specified on the Bundle-Classpath.
The dependencies of com.springsource.org.h2-1.0.71.jar which are being satisfied by com.springsource.org.apache.lucene-2.3.2.jar (which is on the Bundle-Classpath), are not listed in the error message, however, those dependencies which are not satisfied by jars on the Bundle-Classpath are being listed in the error message.
Not quite sure what is happening. What is the rule regarding jar files which are specified on the Bundle-Classpath ? Do their imports (even when they are specified in the Import-Package) element of their manifest, have to be listed in the main project's pom ? Or is this something which the Maven bundle plugin is enforcing ? If the latter is the case, is there a way to get away from the enforcing ?
When you embed any jar via Embed-Dependency tag then the maven-bundle-plugin would analyze that jar also and add the referred packages to the host bundle Import-Package list. Mostly such packages are optional depending on the feature used. For example in your usecase the H2 jar has dependency on Lucene, Servlet API for certain features. if your usage scenario does not require these features then you can mark these packages as optional
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.5</version>
<extensions>true</extensions>
<configuration>
<obrRepository>NONE</obrRepository>
<instructions>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
..
<Embed-Dependency>
h2
</Embed-Dependency>
<Import-Package>
org.osgi.service.jdbc.*;
org.apache.lucene.*;
javax.transaction.*;resolution:=optional,
*
</Import-Package>
</instructions>
</configuration>
</plugin>
In above config we mark such packages as optional. The main problem is to determine the package list depending on your usage
One quick and dirty way is to mark all as optional imports. Should be used as a last resort. As some valid imports would be marked optional and OSGi fwk would not be able to check them.
<Import-Package>
*;resolution:=optional
</Import-Package>
Also note that H2 jar is a valid OSGi bundle so you can deploy it directly.
rule regarding jar files which are specified on the Bundle-Classpath ?
The files which are listed on the bundle-classpath are scanned by maven-bundle-plugin(mbp) to identify imports needed by
each specified jar. Thereby, mbp will add the required imports in the main (your main bundle) manifest.mf.
This does means that the packages should be exported by the outside bundles. If required packages are not found outside of
the bundle then the bundle will not start.
You have 2 solutions to use the third party jars required by your application.
Prepare the OSGi bundle of each and every third party jar. You may find the osgi bundle already created for
spring jars and other open source projects at spring repository here. Just search it perfectely. you will find it.
Use Bundle-classpath:
with this you will have to put your third party dependencies (and "all" their transitive dependencies) in your bundle and specify each jar in Bundle-ClassPath header. With this case, mbp will analyze the bundle classpath jars and try to mess with your import-package header. You just avoid this by including your custom header in pom.xml. If you choose for your custom import-package , be careful to include the required packages from other (outside) bundles correctely in your import-package.
Thumb rule : If your app finds something in your bundle-classpath then it will not go for import-package.
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.