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.
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 am working in a small team (3 persons) on several modules (about 10 currently). The compilation, integration and management of build versions is becoming more and more tedious.
I am looking for a good build / integration tool to replace / complete Ant.
Here is the description of our current development environment :
- Several modules depending on each over and on third party JARs
- Some may export JARS, some export WARS, some export standalone, runnable JARS (with Fat-Jar)
- Javadoc for all of them
- We work with eclipse
- Custom Ant script for each module. Many redundant information between the eclipse configuration and Ant scripts. For example, for the standalone Fat-JAR, we have listed all the recursive dependencies, whereas ideally, it could clearly be imported from the eclipse configuration.
- The source code is versioned using SVN
Here is what I would like a perfect integration tool to do for me :
Automatize the releases and versioning of modules. Ideally, the integration tool should detect if a new version is needed. For example, if I want to release a project A that depends on a project B, and if I have made small changes on the project B locally, then the integration tool should first release a new version of B as well and make A based on it.
Integrate strongly with eclipse, so that it could get the dependencies between modules and third party libs from its configuration. BTW, I would like to continue to configure build path with eclipse without updating some other ".xml" stuff. I saw that Gradle can generate eclipse project files from its configuration, but the counterpart would be great.
Enable a "live" and transparent development on local projects. I mean that I often make small changes on the core / common projects while developing the main / "leaf" projects. I would like to have my changes on core projects immediately available to leaf projects without the need of publishing (even locally) the JARs of my core projects.
Store all versions of the releases of my module on an external server. The simplest (shares folder / Webdav) would be the best. A nice web page with list of modules and delivered artifacts would be great too.
I have looked around for many things. From Ant4eclipse (to integrate the Eclipse configuration into my Ant script), to the Maven / Ivy / Gradle tools.
I am a bit confused.
Here is what I have understood so far:
- Maven is a great / big tool, but is somewhat rigid and obliges you to bend to its structure and concepts. It is based on description rather than on scripting. If you go out of the path, you have to develop you own plugins.
- Ivy is less powerful than maven, it handles less stuff but is more flexible.
- Gradle is in-between. It is general purpose. It enables scripting as well as "convention based" configuration. It integrates Ant and extends it.
So at this point I am looking for actual testimonials from real users.
What tools do you use ? How ? Do you have the same needs as me ?
Does it ease your life or get into the way ?
Are there sample some use cases, or workspace skeletons out there that I could use as a starting point to see what these tools are capable of ?
Sorry for the length of this message.
And thanks in advance for you advice.
Kind regards,
Raphael
Automatize the releases and versioning of modules (...)
The concepts of versioning and repository are built-in with Maven and they could fit here.
Maven supports SNAPSHOT dependencies. When using a snapshot, Maven will periodically try to download the latest available snapshot from a repository when you run a build. SNAPSHOT are typically used when a project is under active development.
Maven 2 also supports version ranges (I do not really recommend them but that's another story) which allow for example to configure A to depend on version [4.0,) of B (any version greater than or equal to 4.0). If you build and release a new version of B, A would use it.
Integrate strongly with eclipse
The m2eclipse plugin provides bi-directional synchronization with Eclipse.
Enable a "live" and transparent development on local projects.
The m2eclipse plugin supports "workspace resolution": if project A depend on project B and if project B is in the workspace, you can configure A to depend on B sources and not on B.jar (that's the default mode if I'm not wrong). So a change on B sources would be directly visible, without the need to build B.jar.
Store all versions of the releases of my module on an external server.
As mentioned earlier, this is actually a central concept of Maven (you don't even have the choice) and deploying through file:// or dav:// are both supported.
To sum up, Maven is (probably) not the only candidate but I'm sure it would fit:
Your project isn't that exotic or complex, there is nothing scaring from your description (some refactoring of the structure will probably be required but this shouldn't be a big deal).
Maven also brings a workflow based on best practices.
m2eclipse provides strong integration with the IDE.
But Maven has some learning curve.
CI tools? To me, there's only one: the Hudson CI.
I've setup a software development environment for Java once, with the components:
eclipse IDE
mercurial
bugzilla
maven
Nexus
Hudson CI
and some apache, mysql, php, perl, python, .. for integration.
The hudson was not integrated with eclipse and that was on purpose, because I wanted to build on a separate server. for all the other tools I had a perfect cross integration (like: mylyn on eclipse to talk with bugzilla, m2eclipse for using maven eclipse, a lot of plugins for hudson, ...)
We've been starting to integrate Gradle into our build process, and I can add to the answers posted already that Gradle would also work. Your assumptions are mostly correct, gradle is more off the cuff, but is powerful and allows for scripting and such within the build itself. It seems that most things maven can do, gradle does as well.
Now for your individual points:
Versioning: gradle supports dependency maps, versioning, and if you add in a CI server, you can trigger automated/dependent builds. For example, almost all of our 'deliverables' are .wars, but we have several code libs (.jars) and one executable .jar in development. One configuration is to make the the wars and the "fat-jar" dependent on the shared code libs. Then, when the shared libs are updated, bump the versions on the shared libs, test the consuming projects, then use Hudson's ability to fire dependent projects to redeploy those. There are other ways, but that seems to work best for us, for now.
Integrate strongly with eclipse: You're right, gradle can generate the eclipse files. We tend to only use the eclipseCp (to update .classpath) task once we get going, as only classpath needs changed. It's kind of quirky (grabs your default JRE, so make sure it's right, doesn't add exported="true" if you need it), but gets you 99% of the way there.
Enable a "live" and transparent development on local projects: This is one I'm not sure about. I've only hacked around gradle in this case; by removing the artifact in the consuming project and marked the shared project as such in eclipse, then reverted afterwards.
Store all versions of the releases of my module on an external server: simple and many approaches are supported, similar to Maven.
As far as examples, the docs for gradle are good, as well as the example projects that come with the full zip. They'll get you up and running fairly quickly.
Have a look at Ant Ivy. http://ant.apache.org/ivy/
There are no silver bullets, but in my experience Maven is a great project management tool. Personally, I like to use a comibnation of subversion (for version control), maven (for project/build management) and hudson (for continuous build/integration).
I find the convention brought by maven is really useful for context switching, and great for dependency management. It can be frustrating if jars aren't in the repositories, but you can install them locally and when you're ready you can host your own private repository which mirrors other places. I have had a good experience using sonar.nexus by http://www.sonatype.com/ . They also provide an excellenmt free book to get you started.
It might seem like overkill now, but setting up a good build / test / integrate / release environment now, will pay dividends later. It's is always harder to retro-fit, and it's something you can replicate easily.
Lastly, I happen to prefer Netbeans integration for maven, but that's just me :)
Some of your topics are part of deployment and release management.
You could check out a product like: Xebia DeployIt
(with an personal edition which is free)
I'm looking for applications that have "rich" maven pom(s) and can show lot of maven capabilities(plugins). These applications are needed as showcase examples - how fast and how many this can be done with maven and appropriate set of plugins.
There are no constraint to technology or application type - it must be opensorce and easy to build. I'm not looking for best one but thouse which are worth to look and build. In yours examples please add comments, what cool features that projects's maven build offer.
Obviously, these poms will be also inspiration to improve my own/others projects poms.
I personally found that Richfaces Photo Album Example was worth to look. In this project (Java EE webapp) there are functional test with cargo and selenium, use of scm plugin (export form svn), generation and deployment of ear to jboss server.
Why not examples from maven books? The should be real projects to convince to maven boss/stakeholders/workmates.
Why I can't get first one project build by maven? Because usually projects (not all) are only built by maven, and contain no additional reports or plugins.
I find Maven's bootstrap build funny: build Maven to build Maven. Note that it is possible to build Maven with Maven already installed but I'm not sure this build shows a wide features set usage.
From this point of view, JBoss AS might already be a better example, but not the "best" (if this has a sense). Actually, I like XWiki's build (Vincent Massol is working there). Or Exo Platform's one (Arnaud Heritier is working there).
I'm pretty sure XWiki and Exo Platform are good examples as their respective build manager have a deep knowledge of Maven (as more or less active maven committers): these build are full of best practices, show the right way to do things, have a clean modules organization, etc. In other words, they are representative of the "state of the art" with Maven.