Geek Answers Handbook

What is a reasonable OSGi development workflow?

I use OSGi for my last project at work, and it's pretty pretty as modular and functional.

But I am not satisfied with the development process. In the end, I plan to have 30-50 separate packages located on the dependency graph - presumably, OSGi is for this purpose. But I can’t understand how to manage dependencies at compile time.

Example: you have packages A and B. B depends on the packages defined in A. Each package is developed as a separate Java project.

To compile B, A must be in the javac class path.

You:

  • Link to the location of the project A file system in the B build script?
  • Build A and throw the jar into the B lib directory?
  • Rely on the Eclipse project link function and always use the Eclipse class path to build (ugh)
  • Use the shared "lib" directory for all projects and dump packages there after compilation?
  • Set up the package repository, parse the manifest from the build script and get the necessary packages from the repository?

Not. 5 sounds cleaner, but also does a lot of overhead.

+7
java compilation ant osgi
source share
4 answers

Basically, you can use:

  • source dependency (with projects tied to Eclipse)
  • binary dependency (using beam jar A)

But since a binary dependency is much cleaner, it is also the kind of dependency that best manages a release management environment like maven.
And you can integrate maven into your Eclipse project via m2eclipse .

The Maven plugin to use will be: maven-bundle-plugin , which you can see in action in

Consider this example in the real world using the Felix Log Service implementation.
The journal service project consists of one package: org.apache.felix.log.impl .
It has a dependency on the main OSGi interfaces, as well as a dependency on OSGi compendium interfaces for specific log service interfaces. The following is the POM file:

 <project> <modelVersion>4.0.0</modelVersion> <groupId>org.apache.felix</groupId> <artifactId>org.apache.felix.log</artifactId> <packaging>bundle</packaging> <name>Apache Felix Log Service</name> <version>0.8.0-SNAPSHOT</version> <description> This bundle provides an implementation of the OSGi R4 Log service. </description> <dependencies> <dependency> <groupId>${pom.groupId}</groupId> <artifactId>org.osgi.core</artifactId> <version>0.8.0-incubator</version> </dependency> <dependency> <groupId>${pom.groupId}</groupId> <artifactId>org.osgi.compendium</artifactId> <version>0.9.0-incubator-SNAPSHOT</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <extensions>true</extensions> <configuration> <instructions> <Export-Package>org.osgi.service.log</Export-Package> <Private-Package>org.apache.felix.log.impl</Private-Package> <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName> <Bundle-Activator>${pom.artifactId}.impl.Activator</Bundle-Activator> <Export-Service>org.osgi.service.log.LogService,org.osgi.service.log.LogReaderService</Export-Service> </instructions> </configuration> </plugin> </plugins> </build> </project>
+2
source share

My company has over 100 projects, and we use Eclipse for dependency management. However, I do not recommend the Necessary Plugins approach for dependency management. It’s best to create plugin projects. Export only packages from each project that you want to see. Then on the import side do the following:

Open manifest editor

Go to the dependencies tab In the lower left corner is the section "Automatic dependency management"

Add any plugins that the current plugin depends on.

After writing the code, you can click the add dependencies link on this tab to automatically calculate the imported packages.

If you run from Eclipse, it will be automatically executed for you at runtime.

The advantages of this approach are that your built packages use only the import / export mechanism in OSGi, unlike something from Eclipse.

If you want to know more, I would recommend visiting this site and ordering a book. Fine.

http://equinoxosgi.org/

+7
source share

Well, do what you needed for a long time, a separate implementation and API ... ok, it's not always that simple on existing systems, but this model has a huge impact for your dollar. When your API is in a separate (much more stable) package / bank, you can compile clients and implementations against this package / jar.

One of the key qualities of a successful package is that it makes as few assumptions about the outside world as possible. This means that you do not need to compile packages that you work with at runtime, I prefer not to do this. You should only compile packages with a minimal set of dependencies. If assumptions are made, they are explicit as imported packages and use of services. Well-engineered OSGi systems try to use services for all interconnects. This model not only gets rid of problems with loading classes, but also makes your assembly more untied.

Unfortunately, most of the code is written in the form of libraries that have a fairly wide interface, because they pass code with many functions provided by services, such as Factories and Listeners. This code is tightly coupled between the implementation and the API, so you need to have the same thing on the class path at compile time and in OSGi. One solution to this problem is to include this type of code inside the package using it (but do not leak objects of this library into other packages). A bit of extra memory consumption, but it saves you some headaches.

So, with OSGi, try creating service-based systems and compiling their service API, not an implementation package.

+5
source share

There is the 6th option that I used for several projects, which should use one Eclipse project (and not a plug-in project, but a regular Java project) and place all the source code there. The assembly file associated with the project will simply compile all the code in one pass and subsequently create packages from compiled classes (using Bnd from Ant or from the upcoming release of BndTools).

This has the disadvantage that it does not respect development visibility and compilation time, but that it is a really simple development model that gives you very fast build and deployment times.

+2
source share

More articles:


All Articles