We use the Apache Felix maven-bundle-plugin to generate a manifest for our fragment bundle. This fragment bundle is intended to override resources on a Liferay host bundle. The Liferay DXP documentation specifies that the developer ought to include a Provide-Capability header in their manifest to override the host bundle's resources. However, the Apache Felix maven-bundle-plugin documentation does not specify how to do so in the plugin, or whether this is possible.
Is there any way for us to add the Provide-Capability header using the Apache Felix maven-bundle-plugin?
For maven-bundle-plugin, you just put <Provide-Capability>...</Provide-Capability> in the plugins configuration making sure to replace ... with the desired value of the header.
In fact, you can add any of the manifest headers defined in the OSGi spec. It's specified in the documentation as follows:
The BND library underlying the plugin defines instructions to direct its behavior. For this Maven plugin, these instructions are issued in the plugin configuration section of the POM file, as was illustrated above. BND recognizes three types of instructions
1. Manifest headers - Any instruction that starts with a capital letter will appear in the resulting bundle's manifest file; the value for the header will either be copied, augmented, or generated by BND depending on the instruction.
Variables - Any instruction starting with a lowercase letter is assumed to be a variable in the form of a name-value pair, such as version=3.0, that can be used for property substitution, but is not copied to the manifest.
Directives - Any instruction starting with a '-' character is considered to be a directive that informs BND to perform some special processing and is not copied to the manifest
Related
I am trying to use configuration file to persist OSGi configuration in Karaf 3.0.0 and having some issue when using property with array of values. My configuration file is placed in /etc folder and looks something like this:
property = ["value1","value2"]
The problem is that array does not get interpreted properly, so in Web Console I see one string value instead of array of values. I figure out that if I use .config as extension for the configuration file, the array gets interpreted properly, but I experience another issue then, like for example that my config file gets overwritten. Is there any way to use .cfg extension and somehow indicate that the property is array?
You might want to take a look at the OSGi Configurer RFP and the OSGi Configurer RFC. OSGi enRoute, which inspired this upcoming spec, has a bundle and some documentation for it.
The Configurer maps JSON to (the spec will be likely YAML) to configuration admin. That said, we generally then use interfaces that define the properties so we can convert the actual configuration type to the type that the code needs automatically. This model is used in DS for configuration and (annotation interfaces in that case). OSGi enRoute has special support for this model with the DTOs service. (Which is also being specified.)
In a specific point in my deployed OSGi bundle, I get a jar file URI in OSGi standard format, jar file that I need to parse for entity classes. So, having the URI like: bundle://233.0:1, would it be possible to get the jar file so that, I will be able to parse it for what kind of entity it has?
Note: I'm trying to solve an issue that I have with OpenJPA, Apache Servicemix and Spring Framework.
If you need any further clarifications, ask me please.
You do not need the jar. You can query the entries of a bundle with the following functions:
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Bundle.html#findEntries(java.lang.String,%20java.lang.String,%20boolean)
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/BundleWiring.html#findEntries(java.lang.String,%20java.lang.String,%20int)
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/BundleWiring.html#listResources(java.lang.String,%20java.lang.String,%20int)
First one returns only entries that is available in the bundle directly. Second one returns entries from the bundle and its fragments. Third one returns entries that the bundle's classloader sees (entries of the bundle, its fragments and entries from imported packages)
Maybe it is a silly question, but what is the best way to test if a Java Archive (jar) file is an OSGi bundle? That is, what are the minimal requirements for the jar to be fully compatible? Is it the mere presence of a META-INF/MANIFEST.MF (I don't think so)? If not, what are the minimal fields that must be provided by this file?
Practically, how should I test if the jar is an OSGi jar?
Look for the Bundle-SymbolicName header in the MANIFEST.MF. This is the only mandatory header in an OSGi bundle, at least since Release 4.0 of the OSGi specification. Therefore if the Bundle-SymbolicName header is defined, then the JAR is an OSGi bundle. If not, then it is just a JAR.
A bundle is a group of Java classes and additional resources equipped with a detailed manifest MANIFEST.MF file on all its contents, as well as additional services needed to give the included group of Java classes more sophisticated behaviors, to the extent of deeming the entire aggregate a component.
The OSGi spec describes the bundle as a "unit of modularization" that "is comprised of Java classes and other resources which together can provide functions to end users.".
a bundle is a JAR file that:
Contains [...] resources
Contains a manifest file describing the contents of the JAR file and providing information about the bundle
Can contain optional documentation in the OSGI-OPT directory of the JAR file or one of its sub-directories
In short, a bundle = jar + OSGI information (specified in the JAR manifest file - META-INF/MANIFEST.MF), no extra files or predefined folder layout are required.
I guess the only qualification be required is that there are a bundle of classes and that it contains a MANIFEST.MF file which contains valid OSGi headers.
Consider this link
As well as this
Answering your question, the only way to test the bundle it to check if the MANIFEST.MF file exists and contains valid headers.
In the configuration of a maven plugin's build, where you are specifying configuration for the "maven-plugin-plugin" there is something called an extractor. I also see it when building the plugin (Applying extractor for language: java).
In this page it specifies many different extractors, but doesn't give a very clear explanation of what they are?
An extractor in that meaning is responsible for extracting the description of the plugin like parameters, injectors etc. which is defined by javadoc things like or annotations or for ant like plugins:
#parameter
#goal
They exists currently for Java and BeanShell.
I am learning osgi framework. It says osgi works on strict class loading environment. I am unable to get what is Strict ClassLoading. Please help i am unable to get the concept
Thanks
Strict classloading means that a module (bundle) has to explicitly specify what it needs. In OSGi this is done using Manifest headers. Import-Package lists the packages and their version ranges the bundle needs and Export-Package lists the packages and their versions the bundle offers. In the OSGi runtime you then have a classloader per bundle that wires the bundles according to the exports and imports.
You should not define these headers by hand though. There is a nice tool named bnd or in maven the maven bundle plugin from felix which does most of the work for you. In this tutorial you find how this works in practice:
http://www.liquid-reality.de/x/DIBZ
You will see that I actually do not define to much by hand there. So build the code and into the meta-inf/Manifest to see what it does.
strict class loading environment means that the appropriate headers of the class need to be specified. for example the class path and the import-package