Ask is moving to Stack Overflow and Serverfault.com! Please use the "opendaylight" tag on either of these sites. This site is now in Read-Only mode

Revision history [back]

click to hide/show revision 1
initial version

Please refer to this question, for general information on Karaf in Opendaylight.

As for the specific questions here.

  1. At the moment, the feature.xml file creation is manual. But there are Archetypes to make it simple to create a project with Features.xml and other Karaf feature related info. Please refer to this awesome intro to Karaf by @jamie.

  2. As far as what goes into this feature.xml is entirely upto you as a developer who proposes to export a feature to the world to make use of. Thumb of rule is that when a feature is installed, it should pull in all its dependencies along and install as a whole. It should not ideally have a pre-requisite of having another feature/bundle to be installed prior to installing that feature. Please think it in terms of a RPM package, where it is self-contained and it pulls in all the required dependencies, when you do yum install or apt-get. As an example, please refer to this ovsdb feature file. If you look for odl-ovsdb-plugin, you will find that it depends on other features such as Controller project's AD-SAL feature , OVSDB Library feature, OVSDB Schema feature and the Bundle that represents the Plugin itself. This makes the OVSDB Plugin self-contained and deployable in isolation.

  3. As far as how would you know the dependency on the external features and availability of these features, it is usually a process of identifying the features that exports the bundles that you are dependent on your Maven pom.xml. There can be a central repository of this information. But AFAIK we don't have it yet and am sure we will get to it some point in near future. I know Mathieu Lemay was working on a tool that will parse the feature.xml from all the project and provide an easily consumable directory. When we have it, I will update this post with the link to it. Till then it is a manual process.

  4. Apart from creating the feature.xml and updating the pom.xml files, depending on the project structure, you may not need to do anything extra. But there are a few cases, some code level stuffs need to be done. For example, if you want to add a Shell command, then appropriate changes need to be done to add a custom Shell command to the Karaf ClI. Something like this. Or if the Karaf dependency results in circular feature-dependency, you may have to reorganize the code a bit to avoid that. There may be other cases, but they don't come top of my mind.

  5. The expected end-result of introducing Karaf in OpenDaylight is to get rid of the pre-baked Editions (which is causing confusions) and let Opendaylight act like a SDN platform where the customers can choose the features of interest rather than the community try to force an artificial edition to the end-customer.

Please refer to this question, for general information on Karaf in Opendaylight.

As for the specific questions here.

  1. At the moment, the feature.xml file creation is manual. But there are Archetypes to make it simple to create a project with Features.xml and other Karaf feature related info. Please refer to this awesome intro to Karaf by @jamie.

  2. As far as what goes into this feature.xml is entirely upto you as a developer who proposes to export a feature to the world to make use of. Rule of Thumb of rule is that when a feature is installed, it should pull in all its dependencies along and install as a whole. It should not ideally have a pre-requisite of having another feature/bundle to be installed prior to installing that feature. Please think it in terms of a RPM package, where it is self-contained and it pulls in all the required dependencies, when you do yum install or apt-get. As an example, please refer to this ovsdb feature file. If you look for odl-ovsdb-plugin, you will find that it depends on other features such as Controller project's AD-SAL feature , OVSDB Library feature, OVSDB Schema feature and the Bundle that represents the Plugin itself. This makes the OVSDB Plugin self-contained and deployable in isolation.

  3. As far as how would you know the dependency on the external features and availability of these features, it is usually a process of identifying the features that exports the bundles that you are dependent on your Maven pom.xml. There can be a central repository of this information. But AFAIK we don't have it yet and am sure we will get to it some point in near future. I know Mathieu Lemay was working on a tool that will parse the feature.xml from all the project and provide an easily consumable directory. When we have it, I will update this post with the link to it. Till then it is a manual process.

  4. Apart from creating the feature.xml and updating the pom.xml files, depending on the project structure, you may not need to do anything extra. But there are a few cases, some code level stuffs need to be done. For example, if you want to add a Shell command, then appropriate changes need to be done to add a custom Shell command to the Karaf ClI. Something like this. Or if the Karaf dependency results in circular feature-dependency, you may have to reorganize the code a bit to avoid that. There may be other cases, but they don't come top of my mind.

  5. The expected end-result of introducing Karaf in OpenDaylight is to get rid of the pre-baked Editions (which is causing confusions) and let Opendaylight act like a SDN platform where the customers can choose the features of interest rather than the community try to force an artificial edition to the end-customer.