Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

OSGi Maven dependencies vs import-packge vs embed-dependency

Tags:

maven

osgi

Could any one tell me what is the difference between

dependencies vs import-packge vs embed-dependency

I am really lost looking at the pom files of sample osgi bundles.

If default maven <import-package>*</import-package> statement resolve dependency on other bundles.

Why does the bundle needs to be included using <dependency> element ?

EDIT : I do not have any sample to put here. Question is "How to wire a bundle as a dependency to access its packages->services in a different bundle?"

like image 427
Sri Avatar asked Dec 16 '15 23:12

Sri


People also ask

What are the different dependencies we need to add in Maven?

There are two types of dependencies in Maven: direct and transitive. Direct dependencies are the ones that we explicitly include in the project. On the other hand, transitive dependencies are required by direct dependencies. Maven automatically includes required transitive dependencies in our project.

What is import package in POM xml?

<import-package>:import packages means including a existing jar. you can include the third party jar using it. suppose you have a another different project (like web service calls) in your complete project. then you can include it using import packages.

What is import in Maven?

The import scope can be used to include dependency management information from a remote POM into the current project. One of the limitations of this is that it does not allow additional excludes to be defined for a multi module project.

How do dependencies work in Maven?

Dependencies are external JAR files (Java libraries) that your project uses. If the dependencies are not found in the local Maven repository, Maven downloads them from a central Maven repository and puts them in your local repository. The local repository is just a directory on your computer's hard disk.


1 Answers

Maven provides an extensive dependency model. A project has a pom, that pom specifies its dependencies on other poms. This is transitive so having one dependency can download half the internet. In maven you can specify that you need a dependency on your compile class path or in your runtime class path.

In OSGi you should create a bundle that can be used in different environments. For this reason, a bundle is a JAR that makes its dependencies explicit. Just like Maven, you can let a bundle depend on another bundle (Require-Bundle). However, requiring another bundle turns out to be quite brittle.

  • It tends to create large dependency graphs
  • You easily get in a situation you need to the same artifact in different versions
  • You require way to much since you often only need a part of another bundle
  • Often you like to use a different implementation

OSGi therefore has a native dependency model based on capabilities. Package exports are a capability. In OSGi, Bundle A does not depend on Bundle B but it depends on package b. (And packages are supposed to represent a contract/API.) Any bundle that exports package b will the satisfy bundle A. This model has numerous advantages, its biggest advantage is that it is not transitive. This provides enormous flexibility in deployment time.

In OSGi, a key goal is to minimize the dependencies and only depend on well defined API, never implementation, so the bundle is easy to use in many different contexts.

So how do you construct that in maven?

In general you let bnd analyze your code. It will then create a manifest that expresses precisely what packages your bundle depends on.

However, the way a lot of code in open source is structured it is likely that you do not depend on just API. So how do you handle these implementation dependencies?

With the embed dependency option you drag in ALL transitive dependencies from the maven pom (and that can be a lot) are dragged in. I would not use this. It is quick but also dirty since you have no idea what you drag in.

In general I design bundles carefully. bnd can therefore specify which packages from other artifacts on your build path should be included. There is even a way to let bnd calculate what is needed from specific namespaces:

   Conditional-Package: aQute.lib.*

This rarely works perfect the first time, you will find you miss stuff the first time you run so it will require some iterations. However, at least you know what is inside your bundle.

like image 93
Peter Kriens Avatar answered Sep 28 '22 05:09

Peter Kriens