Setting up Eclipse for Spring Dynamic Modules development

Start up Eclipse with a new (empty) workspace. You can use an existing workspace if you like of course, but I'll assume here you are creating a workspace dedicated to developing with Spring Dynamic Modules.

Define a classpath variable for your maven repository

Define your maven repository to eclipse by running the maven command:

$ cd workspace_dir $ mvn -Declipse.workspace=. eclipse:add-maven-repo 

This command creates an Eclipse classpath variable M2_REPO that points to your local maven repository.

Configure the Package Explorer to show working sets

Click on the menu triangle at the far right of the Package Explorer menu bar and select "Top Level Elements" -> "Working Sets".

This configures the Package Explorer to show groups of projects known as working sets as the top-level entity in the view. Right now you'll only have one working set called "Other Projects" which is a catch-all working set for anything that is not in a user-defined working set.

Import the Third-Party Library OSGi bundle projects

From the File menu select "Import..." and the in the "General" category select "Existing Projects into Workspace".

Click the browse button next to "Select root directory" and select the folder spring-osgi/spring-modules/spring-required-libraries. Eclipse will populate the dialog with all the Eclipse projects found under that root that do not already exist in your workspace. Click on "Finish".

Note, I'm assuming that you have already checked out the Spring-OSGi source tree into a folder "spring-osgi" on your machine - if not you need to do that now before you can complete this step. Instructions for checking out the source are available.

Now select all of these newly created projects in the Package Explorer, and with them still selected click on the menu triangle in the Package Explorer tool bar and select "Configure Working Sets".

Click on "New" and create a working set called "Third Party Library Bundles". The projects that you had selected in the Package Explorer will all be included as members of the working set by default. Click on "Finish" to create the working set, and then "OK" to close the outer dialog.

Import the Spring modules bundle projects

From the file menu select the option to import existing projects into the workspace again, and this time browse to the spring-osgi/spring-modules folder. Import all the projects found. These will be placed in the "Other Projects" working set by default. Select them all and then create a new working set called "Spring Module Bundles" to contain them.

Note that a number of these projects have build errors. This is expected at this stage. From the Problems view menu (triangle on the far right-hand side of the view toolbar again) select "Configure Filters" and then choose "On any element in same project".

Now click on e.g. the spring-hibernate3 project. You'll see error messages such as "No available bundle exports package 'org.hibernate.cfg'". This is because we haven't yet created a third-party bundle project for the hibernate libraries. All of the core Spring modules should build without errors though. If you need to work with one of the projects showing build errors, you'll need to create an OSGi bundle or bundles for the missing dependencies. The quickest way to do this is to select "New" -> "Plug-in Development" -> "Plug-in from existing JAR archives". Select the jars that you want to package as an OSGi bundle, and Eclipse will create a plug-in (OSGi bundle) project for you. After this project has been created, you'll need to "clean" the spring-module projects that depend on it before Eclipse will remove the error markers.

Import the remaining projects

Using the same approach as before, import existing projects into the workspace and point at the "spring-osgi" root folder. This will import all the remaining projects into your workspace. You can further refine these into additional working sets if you wish (e.g. you might create a working set for the samples). After creating additional working sets in the package explorer, you can simply drag projects into the working set you want them to be part of.

This is what my Package Explorer looks like:

Launching Equinox inside the Eclipse IDE

You can run any of the unit and integration tests in the source tree simply by choosing "run as..." -> "JUnit test" from the context menu. You can also configure Eclipse to start up Equinox using the Spring-OSGi bundles. Here's how you do this to run the "Simple Service" example:

1. Open the "Run..." dialog and select the "Equinox OSGi Framework" category
2. Click on new to create a new launch profile, I called mine "Simple service in equinox".
3. On the plugins tab, choose the plugins you want to run with. Start by clicking "deselect all". I've added jakarta.commons.logging, log4j, org.aopalliance, org.springframework.aop, org.springframework.beans, org.springframework.context, org.springframework.core, org.springframework.osgi, org.springframework.osgi.samples.simpleservice, and org.eclipse.osgi.
   
4. Click "Apply" and then "Run".

This will start up equinox (you should see the "osgi>" prompt in the console window). Type 'ss' to see a short status summary of the bundles installed, and 'help' to get an overview of the commands available.

One snag you may have spotted is that out of the box when run in this way the configuration files in META-INF/spring aren't picked up by equinox (because in the exploded project, these are packaged under target/classes). This is only an issue when running inside Eclipse in this way (using the integration test harness or maven build, the resources are found quite happily. You can fix this in one of two ways: create a symbolic link 'spring' from META-INF to src/main/resources/META-INF/spring in the "Simple Service Sample bundle" project (I made my link on the filesystem using 'ln -s' rather than within eclipse. The alternative is to create a copy of the spring folder underneath META-INF. You will need to do this trick for each Spring bundle project you create and want to launch under Eclipse in this manner.

With the link defined, the simple service bundle should now create 2 beans in its application context, and export one of them as a service.