The SpringSource AP supports different deployment units as already outlined earlier. The AP Tools define specific project types to support the development of OSBi and PAR projects.
There are two New Project Wizards available from the Eclipse that allow for creating new OSBi bundle and PAR projects. The projects created by the wizards are deployable to the integrated Application Platform instance without further to do.
Those wizards create the required MANIFEST.MF file and appropriate manifest
headers. The New PAR Project wizard also creates a file called par.xml in
the root of the PAR project that allows users to manage the bundles contained in the
SpringSource Application Platform archive.
![]() | Note |
|---|---|
The par.xml file is only required for tooling to keep track of the
depending projects. It is not required by the Application Platform at runtime.
|
To migrate an existing Java Project to be used with the Application Platform the tooling provides a migration action that adds the required tooling meta data to the project. The migration will not change your project's source layout.
Use the context menu action of a project in the Package or Project Explorer and select "Spring Tools -> Convert to OSGi bundle project".
Working on OSGi bundles one of the most interesting and challenging aspects is to define
the package, bundle and library imports in the manifest and then keeping this in sync
with your compile classpath either in Ant and Maven or Eclipse. In most cases that
required to manually set up the Eclipse classpath. At the end the Eclipse compile
classpath is still different from the bundle runtime classpath as normally an entire
JAR file is being made available on the Eclipse classpath but not necessarily at runtime
as of the explicit visibility rules defined in Import-Package headers.
The AP Tools address this problem by providing an Eclipse classpath container that
uses an Application Platform specific dependency resolution mechanism. This classpath
container makes resolved dependencies available on the project's classpath, but allows
only access to those package that are imported explicitly (Import-Package)
or implicitly by using Import-Library or Import-Bundle.
To use the automatic dependency resolution a OSGi bundle or PAR project needs to be targeted to a configured SpringSource AP instance. This can be done from the projects preferences and selecting the runtime on the "Targeted Runtimes" preference page.
![]() | Note |
|---|---|
| In most scenarios it is sufficient to target the PAR project to a runtime. The nested bundles will automatically inherit this setting. |
After targeting the project or PAR you will see a "Bundle Dependencies" classpath container in your java project. It is now save to remove manual configured classpath entries.