I saw there are some community osgi.enroute, equinox and etc are encouraging bndtools for osgi bundle. However, there are a lot of a special key that I have never seen and can't find in their official website. For e.g.
Require-Capability:\
osgi.service;filter:="blahblahblah";effective:=active
Provide-Capability: osgi.service;objectClass=net....
And there are sometimes doing like
META-Persistence:
Webcontext-path:
Ok, where is this documentation from? Who the hell know if putting like this it will auto look up? Which mean I put JDBC-Driver then it will lookup?
Are they any bndtool cheat sheet or docs that can refer all this stuff.
As I know maven felix plugin had helped us to bundle nicely private export and import. What for I want to migrate to bndtools?
And I see apache karaf(popular OSGI runtime) is still using felix maven plugin which is more clear and understandable.
Is this a reason why OSGI until now still less popular than other JAVA framework? Can I still stick to the maven Felix plugin bundle rather than using these complicated tools?
The newest enroute examples use a maven build. So they are not very different from apache karaf builds. For creating bundles with maven you have two choices. The maven-bundle-plugin (from felix) and the bnd-maven-plugin from the bnd community.
Both use bnd under the hood, so they only have small differences. bnd-maven-plugin uses bnd.bnd by default for configuration. maven-bundle-plugin can also use this configuration style. I see the trend that many project use bnd-maven-plugin as it is more up to date with bnd versions but you can use both.
The real differences are with building the deployment artifact. In bndtools you build a jar out of a bndrun file while in karaf you usually create a feature file. This is where you really have to decide which way you go. If you use a self contained jar for your application then bndtools is a great choice. If you plan to deploy into karaf then karaf features are the best choice.
Btw. In both cases bndtools plugin for eclipse provides some nice support. Especially looking into the Manifest of jars and editing support for bnd.bnd files is nicely supported.
Regarding configurations needed in the bnd.bnd file. These configurations are needed in the same way if you use the felix maven-bundle-plugin.
The good news is that if you use the newest specs / examples then you rarely have to touch the bnd.bnd or the plugin config in maven. There are annotations for almost every needed configuration. There is good documentation inside the OSGi specs themself but the easiest approach is starting with examples.
Related
i'm trying to integrate drools engine inside an Apache Felix container.
I can't find ANY official resource regarding the installation process. The official documentation of drools 6.4.0.Final only state that drools is OSGi ready
Can someone give me useful informations ?
What I did so far:
I've tried integrating the OSGi bundle that is contained in the Drools zip distribution that can be downloaded from the official site. I couldn't find documentations out there neither technical release notes in the .zip file, so I started adding to my target platform (based on Apache felix) the kie-ci-osgi-6.4.0.Final.jar contained in the osgi-binaries folder.
I saw that there were lots of unresolved dependencies, so i tryed to manually add every jar, before giving up because I couldn't find nor understand what's was happening.
After that I tryed the same flow with this jar. I also dowloaded with maven cli every dependencies without success
March 2016.
To analyze huge OSGi project with 100 bundles I would like to use visual tool (or some console or file output) to see all dependencies and interconnections between bundles (not classes)
What I found so far
How to analize/visualize OSGi, maven dependencies -> Is actually for Eclipse plugins only
http://www.ibm.com/developerworks/library/os-eclipse-dependencyvisualization/index.html
How can I visualize jar (not plugin) dependencies? -> is for class dependencies
View osgi bundles' dependencies? -> is 6 year old and was asking for Eclipse tools, while I am good with any that would give actionable upon results.
XRay shows service dependencies. For a really good OSGi applications that is service oriented this should be all the relevant information you want to know.
OSGi enRoute makes it rather nice to play with this. Follow the quick start tutorial and you will run into XRay at the application section.
I am getting in touch with OSGi and trying to setup a project using Apache Felix and Maven. I'd like to use a Multi-Module build and declarative services. The project is hosted on GitHub: osgi-maven-example (Note that the link points to a specific commit and not to the HEAD of the repository.)
I have got a few questions about the overall setup of the project:
According to Neil Bartlett the bnd-maven-plugin should preferably used over the Apache Felix Bnd Plugin because it respects Maven's lifecycle. Judging by the age of the bnd-maven-plugin, this seems to be a relatively new approach and I am therefore not sure if it is a good idea to do so.
I am using the declarative services package (org.apache.felix.scr.annotations) from Apache Felix to define my components. These annotations are used by the maven-scr-plugin to generate service descriptors which are included in the MANIFEST.MF by the use of the following line in the bnd.bnd file: Service-Component: OSGI-INF/*.xml. Is this the way declarative services are intended to be used?
IntelliJ displays a warning in the GermanGreeter-class:
What exactly does this mean? Do I need to care about this? How can I fix it?
Although I am pretty happy over this working example, I am curious if I am using all these technologies in their intended way and I would be very grateful if I could get some feedback on the overall setup before I am starting to use it in a bigger project.
There is now an official set of annotations for DS, under the package org.osgi.service.component.annotations. These annotations are packaged in the jar "compendium" (org.osgi/cmpn), and bnd has a directive to generate components descriptors : -dsannotations : *
the first part of your question is subject to opinions... maven-bundle-plugin is more "maven centric" : it's more easy to integrate it in a maven build. bnd-maven-plugin is more "bnd centric" : you manipulate standard bnd files, but it broke some maven convention. both have advantage and inconvenient
I agree with Jeremie that you should use the standardized annotations. They can be used with both the felix maven-bundle-plugin as well as the bnd-maven-plugin. For an example of the first see Apache Karaf Tutorial part 10 - Declarative services. For the second this post from Neil is a good source of informations. You should not need the scr plugin.
The maven-bundle-plugin is quite stable and easy to use. The problem with it is that it redefines the maven lifecycle which can cause problems with some project setups. The bnd-maven-plugin needs a bit more maven xml in the parent but then has the advantage that it fits better into complex builds as it does not tweak maven.
For what reasons would I want to make my project an OSGI bundle as opposed to just a standard JAR package? Does it only make sense if it is going to be used by an application that uses an OSGI framework (eg: Equinox/Eclipse)? Or is it also useful from a development point of view, ie: being able to easily reuse my OSGI bundle by other projects during Eclipse development?
OSGi provides support for modules, you could control the dependencies. Each module may include and exclude packages from other bundles. You can also replace bundles during runtime. Making a whole project a single bundle has none of these benefits. I would only wrap a jar like a jdbc driver as bundle if it is not available as an OSGi bundle.
First check whether your project would have a benefit. Then identify which modules should be a bundle.
If your project is a public or open source library, then please do make it an OSGi bundle. This will be of great help to OSGi developers who may want to use your library.
On the other hand if your library is private then the benefits of OSGifying it are limited. Mostly it will be an advantage if you decide to adopt OSGi strategically later. You may also derive some benefit from the explicit dependencies, i.e. you can look into the bundle to work out exactly what it depends on.
There is no runtime cost of doing this. The OSGi data in the manifest is simply ignored by non-OSGi runtimes.
You will have to generate the OSGi manifest though as part of your build step. The best tool to use for this is Bnd, which can be easily integrated into any ANT build -- use it as a replacement for the "JAR" task. If you are building with Maven, then use the Maven Bundle Plugin (which uses Bnd internally).
This is useful only if it's going to be used from within an OSGi container as you mentioned.
If you are searching an answer on why it is useful in general is something you can find a lot just by googling - start from Wikipedia:
http://en.wikipedia.org/wiki/OSGi
In general, I'd say OSGi's main benefits are encapsulation/versioning, solving JAR hell and management provided by the framework, which may or may not be interesting to you depending on your project.
I definitively suggest reading about OSGi if you haven't already - it's very interesting technology. I would suggest reading Neil Bartlett's articles on EclipseZone - this is the first one:
http://www.eclipsezone.com/eclipse/forums/t90365.html
There are a bunch of them, so google them - very interesting read, which will also give you an idea whether this is something you should consider.
SpringSource is a big proponent of OSGi, so it's worth taking a look there, too:
http://www.springsource.org/osgi
If you ever plan on using it in an OSGi context then you might as well make it a bundle. I don't know that there are any negative affects to making it a bundle, whereas if you don't make it a bundle and find out later on that you need it to be then you may have to go back and fix it. Aside from that I personally don't know of anything other than OSGi which uses the manifest meta information - but like I said; I don't think it will hurt.
OSGIfying a project will allow OSGI to be used for dependency management in Eclipse instead of the standard Eclipse project build mechanism, or an external dependency management tool such as Ivy or Maven. Making a project into an OSGI bundle allows you to express that project's package dependencies as bundle dependencies (if a bundle exists for the package dependency) which will be handled by the OSGI framework instead of those other mechanisms (standard Eclipse project build/Ivy/Maven).
Standard Eclipse project dependencies are established by specifying other projects and libraries on your project's build path. Converting to OSGI would replace your build path references with MANIFEST.MF import-package or required-bundles declarations.
Advantages of using OSGI for dependency management over the standard eclipse mechanism are:
re-export dependences: your bundle can re-export their dependent packages which means code relying on your bundle doesn't also have to rely on your bundle's dependants if it also uses them
version management: so you can specify the minimum and maximum expected version of a dependency.
See also Should I use Eclipse plug-ins (or OSGi Bundles) as a plain dependency management tool?
I'm just getting started with OSGI development and am struggling to understand how best to handle dependant JARs.
i.e. if I'm creating a bundle the likelyhood is that I will need to use a few 3rd party JARs. When I create my bundle JAR to deploy to OSGI, obviously these 3rd party JARs are not included and thus the bundle will not run.
I understand that one option is to turn these JARs into bundles and also deploy them to the OSGI container. However if they only need to be used by the one bundle this doesn't seem ideal.
What is the best solution to this? Can the JARs be embedded within the bundle JAR and if so is this a reasonable approach?
You can include a third party jar inside your bundle by adding the third party jar to the root directory of the bundle jar file and then adding a bundle classpath header to the bundle's manifest, e.g.:
Bundle-ClassPath: .,my3rdparty.jar
If you want to place third party jar to subdirectory, specify the path without using heading ./, e.g
Bundle-ClassPath: .,lib/my3rdparty.jar # (not ./lib/my3rdparty.jar)
I would almost always bundle each jar separately. OSGi itself is meant for modularization and you take the whole system ad absurdum by not doing this.
If you want to convert JARs into bundles you might want to use the BND Tool written by Peter Kriens. But first I would suggest you look for the bundle in the SpringSource Enterprise Bundle Repository if they haven't already done the work for you.
It is possible to embed non-OSGi dependencies into the bundle.
An easy way to do this is to use Maven to manage your dependencies and Maven Bundle Plugin to build your bundle. Take a look at the <Embed-Dependency> and <Embed-Transitive> instructions of the Maven Bundle Plugin described in the section Embedding dependencies of the plug-in documentation page.
As Roland pointed out this is not an ideal solution with respect to the intentions of OSGi, i.e. modularization and reuse of individual modules. However it might be pragmatic solution for time being until the 3rd-party dependencies can be converted into OSGi bundles.
This thread is a bit old, but I wanted to point out one of the limitations of embedding dependencies. Recall that dependencies are at the jar level, but when you export packages some may need to come from the embedded dependencies. If this happens, you will end up with duplicate classes, one set inline in the top level bundle and another in the embedded jar. Of course, you can inline the entire embedded jar, but before you know it this propagates across your entire dependency chain. This is just one of the problems that Roland and others refer to.
Here is an example if you are using the Maven Bundle Plugin.
Note: This plugin automatically imports packages that your dependencies need. This may or may not be a problem for you. Thankfully, you can suppress the packages you don't really need to import (see below).
<Import-Package>
<!-- this was imported by one of the dependencies; I don't really need it -->
!org.apache.jackrabbit.test,
*
</Import-Package>
<Include-Resource>
lib/concurrent-1.3.4.jar,
lib/jackrabbit-core-2.6.5.jar,
lib/jackrabbit-spi-2.6.5.jar,
lib/jackrabbit-spi-commons-2.6.5.jar,
lib/lucene-core-3.6.0.jar,
lib/tika-core-1.3.jar
</Include-Resource>
<Bundle-ClassPath>
.,
concurrent-1.3.4.jar,
jackrabbit-core-2.6.5.jar,
jackrabbit-spi-2.6.5.jar,
jackrabbit-spi-commons-2.6.5.jar,
lucene-core-3.6.0.jar,
tika-core-1.3.jar
</Bundle-ClassPath>
Can we use OSGI to override the bootstrap classloader jars loaded during runtime, like if we wanted to override JAXP1.4.5 available with Java7 to JAXP1.6, there is -Dendorese feature to override the default API to upgraded API. Can we able to do this thing with the help of OSGI.