APAM/APAM Details/APAM OBR Interaction

From Wiki Adele Team
< APAM‎ | APAM Details
Revision as of 17:45, 17 October 2012 by Mehdi (talk | contribs)
Jump to: navigation, search

Any component definition can make references to other components (provided resources, dependencies, property definitions and so on). In order to compile a component, the definition of these other Apam components must made available to be read.


Default behavior

Apam does its best to synchronize the Maven and the Obr repositories when compiling. By default, these definitions will be searched in the default Maven repository which is supposed to contain the OBR repository (i.e. the “repository.xml” file). If using the maven plugins in the usual way, there is nothing to indicate to Apam.

Customize compilation

For advanced users, if you indicate in your component .pom different Maven repositories in which your bundle will be deployed, and different OBR repositories in directories different from the Maven directories, you must also provide the information to Apam. The Obr repository can be set for in the component .pom, in the “maven-bundle-plugin” using the <obrRepository> tag as follows:


Apam will use the same repository, nothing more is needed if all the components are in this repository. However, if more than one repository are needed, you should use the <dependencyObrList> tag in the “ApamMavenPlugin “ as follows:

	    <param>http:/…. /repository.xml</param>
	    <param>https:… </param>

The <noLocalObr> tag indicates if the Maven local repository should be considered. By default the value is false.

At compilation, the Apam Maven plug-in adds in the OBR repository all the attributes initialized, the default values and the final attributes, exactly in the same way as found in Apam ASM. Therefore the filter indicated in a resolution can find the right component, in the same way, in the ASM or in the Obr repository. The Apam Maven plug-in also adds in the OBR repository the dependency toward the provided specification, along with the right version.

Runtime : Execution and OBR repositories

At execution, Apam (more exactly managers like OBRMan), can deploy dynamically Apam components (more exactly the bundles containing these components) potentially from remote repositories. These managers receive their model each time a composite type is deployed, and should resolve the dependencies with respect to the current composite type model.

In the special case of ObrMan, the model associated with composite type “Compo” is found in the directory “${basedir}/src/main/resources/Compo.ObrMan.cfg”.

That file has the following syntax:

LocalMavenRepository = [true | false]
DefaultOSGiRepositories = [true | false]
Repositories=http:/……../repository.xml \
 File:/F:/…… \
Composites=S1CompoMain CompoXY …

Attribute LocalMavenRepository is a Boolean meaning if yes or not, the local Maven repository, if existing, should be considered. Attribute DefaultOSGiRepositories is a Boolean meaning if yes or not, the Obr repository mentioned in the OSGi configuration should be considered. Attribute Repositories is a list, space separated, of OBR repository files to consider. The order of this list defines the priority of the repositories. Attribute Composites is a list, space separated, of Apam composite types. It means that the repositories defined for that composite type should be considered. The order of this list defines the priority of composites repositories. These composites must be present in Apam at the time the composite is installed, they are ignored otherwise.

The list of repositories defined by this file is the list of repositories to associate with that composite type.

The order of the attributes in the file defines the priority in which the resolution will be done by the OBR, for example:

In this model:


First, we will check the LocalMavenRepository, then DefaultOSGiRepositories then Repositories and finally Composites.

The default models associated with the Apam root composite type are found in the OSGi platform under directory “./conf/root.OBRMAN.cfg”. If this file is missing, its content is assumed to be LocalMavenRepository=true DefaultOSGiRepositories=true. For composites types that do not indicate an OBRMAN.cfg model, ObrMan uses the root model.

Apam relies on the OBR mechanism for dynamically deploying the bundles containing the required packages. For that reason the Apam Maven plug-in adds in the OBR repository the dependency toward the Apam specifications, along with the right version.