Issues with Shared Service Bundle Project template and STS MF handling

I'm doing some proof-of-concept work with OSGi bundles and have run into some issues with the Shared Service Bundle Project template and the project that it creates. Along the way, I'm also having some issues with how STS handles MANIFEST.MF and TEST.MF references.

To illustrate these issues, I've attached a sample project that I created from the Shared Service Bundle Project. This has been modified some (and this goes to one of the issues with this template), mainly to update library versions from, e.g., Spring 2.5.6.A to 3.0.5.RELEASE, add versions to the various plugins (not necessary, but I get warnings from Maven if not), and enable Maven dependency management.

So here are the issues I've found:

• Maven dependency management isn't on by default. This causes a bunch of errors right out the gate because of course the required dependencies aren't downloaded.
• The new project refers to the SpringSource dm Server (Runtime) 1.0. This is very confusing because that support is deprecated, but it takes a bit of digging before that becomes apparent.
• It'd be nice if the referenced JRE was the workspace default. It always comes out as JavaSE-1.5, but I'm using a 1.6 SDK.
• Spring and other library versions in pom.xml are quite old.

OK, those are general issues with the new project template, but now here's the real issue, at least in STS.

I always get an error in the MANIFEST.MF related to this line:

Code:

---

Import-Library:
 org.springframework.spring; version="[2.5.6.A,2.5.6.A]"

---

In my updated project, I've referenced Spring 3.0.5.RELEASE and changed the MANIFEST.MF reference accordingly:

Code:

---

Import-Library:
 org.springframework.spring; version="[3.0.5.RELEASE,3.0.5.RELEASE]"

---

No matter, I always get this error in STS:

Code:

---

Description        Resource        Path        Location        Type
Import-Library: org.springframework.spring [2.5.6.A, 2.5.6.A] could not be resolved        MANIFEST.MF        /TestOSGiService2/src/main/java/META-INF        line 10        SpringSource Bundle Dependency Problem

---

And strangely, in one project that's no different from the other test projects I'm creating, I also get this:

Code:

---

Description        Resource        Path        Location        Type
Import-Bundle: com.springsource.org.junit [0.0.0, oo) could not be resolved        TEST.MF        /TestOSGiService/src/test/java/META-INF        line 1        SpringSource Bundle Dependency Problem
Import-Bundle: com.springsource.slf4j.api [1.5.6, 1.5.6] could not be resolved        TEST.MF        /TestOSGiService/src/test/java/META-INF        line 3        SpringSource Bundle Dependency Problem
Import-Bundle: com.springsource.slf4j.org.apache.log4j [1.5.0, 1.5.0] could not be resolved        TEST.MF        /TestOSGiService/src/test/java/META-INF        line 4        SpringSource Bundle Dependency Problem
Import-Bundle: com.springsource.slf4j.simple [1.5.6, 1.5.6] could not be resolved        TEST.MF        /TestOSGiService/src/test/java/META-INF        line 5        SpringSource Bundle Dependency Problem
Import-Bundle: org.springframework.test [0.0.0, oo) could not be resolved        TEST.MF        /TestOSGiService/src/test/java/META-INF        line 2        SpringSource Bundle Dependency Problem

---

I'm able to build these projects cleanly with Maven, but I haven't yet been able to tell whether the OSGi functionality works properly yet. I'm going to just ignore these errors for now and continue working on my POC app, but any help to get these things cleared up would be greatly appreciated.

For reference, my configuration is:

• 64-bit CentOS 5.5
• JDK 1.6
• STS 2.6.0 patched up

I tried to run this same thing on Windows, but I get an error trying to install the dm Server plugin, so I can't reference the Virgo run-time there. I'm going to try to figure out what's going on with that, but I'll post in a separate message for that problem.

If you need any more info, let me know.

As a follow-up to this, I got a package up and running with the changes I mentioned (library versions, etc.). When I went to upload this into Virgo, the bundle failed with the following error:

Code:

---

Caused by: java.lang.IllegalArgumentException: Cannot locate bean named 'exampleServiceImpl' inside the running bean factory.

---

The reason for this seems to be that the bean is referenced in the osgi-config.xml configuration file, but instantiated indirectly by the <context:component-scan> in the module-config.xml. I don't know if module-config.xml is even referenced or not, but the <context:component-scan> doesn't seem to work at all: the reference to exampleServiceImpl demonstrates that osgi-config.xml is getting loaded, so I moved the <context:component-scan> tag there, with the same result. I replaced the <context:component-scan> tag with the following:

Code:

---

<bean id="exampleServiceImpl" class="org.nrg.xnat.services.internal.ExampleServiceImpl"/>

---

At that point, the bean is found properly. I still get an error:

Code:

---

Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory

---

I think that's because the changes in the Maven plugins is causing an issue with how the bundle is packaged. The MANIFEST.MF that gets placed in the service bundle contains only this:

Code:

---

Manifest-Version: 2.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: rherri01
Build-Jdk: 1.6.0_23

---

So the Import-Package statement that brings in the ACL library just isn't there. This may actually be behind the loading issues with exampleServiceImpl as well, I dunno...

To clarify, my goal here is not to whine and complain, although I'm doing that quite successfully :) But I'd really like to help get these project templates into shape so that we can have a workable starting point for OSGi services and service consumers.