6.3. Setting up Eclipse Projects

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.

Creating New 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]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.

Migrating existing Java Projects

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".

Resolving Bundle Dependencies

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]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.