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.
Related
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.
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'm on a Enterprise Project that requres a lot of Java Plug-ins.
Every plug-in has the same structure, that is something like
com.mysite.XXXX
---com.mysite.XXXX
------Activator.java
---com.mysite.XXXX.impl
------XXXXMyClass1.java
------ ..............
------XXXXMyClassN.java
---META-INF
------MANIFEST.MS
---XXXXFolder
------XXXX.xml
this structure is repeated for 4-5 times for each development, so I waiste a lot of time just for creating the project structure copy-pasting and renaming a blank template, and every member of my team has this problem.
I'd like to create a way to auto-generate the java projects and the relative structures. This pattern will remain the same for years. I'm not looking for the cleanest and finest solutions, something dirty but working would be ok :) .
Can you help me? What technologies can I use?
I would try creating a custom Maven archetype
We use maven archetypes to create plug-in projects with associated test fragments. The approach is described here in more detail.
As others have said, generate your bundles using Maven.
You can use the maven-bundle-plugin to create your OSGi manifest rather than creating it manually.
Once you have a working Maven build, as mentioned above, create an 'archetype' for that, and your other developers can use that to create the framework of a plugin application.
I came to a grinding halt in trying to debug a problem I am having with Spring 3.1 ( I put a bounty on it FWIW ). So, I would like to take the spring-security and spring-ldap source code, put my own log4j statments in, compile it and run my webapp in Tomcat 6.
What is the most sensible way to do this?
Include my "customized" libraries in the WEB-INF/lib of my Maven based project or do I put the altered libs in the tomcat\lib dir?
Can I do this using only Maven? I recently learned Maven to fix a proble and I would like to catch my breath before learning gradle if I can.
I don't want to do this for all of Spring and all of Spring-Security.
How would I set it up in maven/my pom.xml?
I realize the new tools make all of this easier than it probably feels to me, but compiling libraries from source has been a terror most of my life so I would like some tips and instructions to make it as easy/fast as possible.
Thanks
You can do this using only maven:
Either: Use the same POM as the spring people do. That way the new jar that falls out of your code will overwrite the one delivered by spring.
Or: Use the same POM, but increase the Version Number (to the next SNAPSHOT ) and change the dependency in your pom to that version. (EDIT: read Roy-Truelove 's comment below, its very correct indeed.)
I would recommend the latter variant.
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?