Comments on: OSGi Development Tools in STS 2.0

By: James Governor's Monkchips » Can Paremus Make OSGi Nimble?

James Governor's Monkchips » Can Paremus Make OSGi Nimble? — Fri, 12 Mar 2010 13:44:57 +0000

[...] fix, another client – SpringSource implements its own Spring Dynamic Modules Framework. SpringSource Tool Suite version 2.0 packages some tooling for building modules and managing dependencies [...]

By: Travis

Travis — Wed, 23 Dec 2009 20:18:36 +0000

When I create a new Shared Service Bundle Project using the Spring Template Project, the src/test/META-INF/TEST.MF file has references to com.springsource.org.junit, etc but Eclipse can't resolve any of the references:

Import-Bundle: com.springsource.org.junit [0.0.0, �) could not be resolved
Import-Bundle: org.springframework.test [0.0.0, �) could not be resolved
Import-Bundle: com.springsource.slf4j.api [1.5.6, 1.5.6] could not be resolved
Import-Bundle: com.springsource.slf4j.org.apache.log4j [1.5.0, 1.5.0] could not be resolved
Import-Bundle: com.springsource.slf4j.simple [1.5.6, 1.5.6] could not be resolved

Is there some additional configuration I need to do?

Thanks!
Travis

By: SpringSource Team Blog » SpringSource Tool Suite now free

SpringSource Team Blog » SpringSource Tool Suite now free — Fri, 08 May 2009 06:53:55 +0000

[...] OSGi Development Tools in STS 2.0 [...]

By: IT Technology And Something » Working with Maven and SpringSource dm Server

IT Technology And Something » Working with Maven and SpringSource dm Server — Wed, 18 Mar 2009 02:32:50 +0000

[...] project dependencies was all based around Eclipse. The STS 2.0 RC discussed by Christian Dupuis here now has support for a separate test classpath using a proprietary TEST.MF. To me this still poses [...]

By: Eclipse based SpringSource Tool Suite 2.0 Released

Eclipse based SpringSource Tool Suite 2.0 Released — Tue, 17 Mar 2009 20:04:48 +0000

[...] 2.0 introduces new features and enhancements, including Project Creation Wizards, a rich forms-based Spring Configuration [...]

By: SpringSource Team Blog » Announcing SpringSource Tool Suite 2.0

SpringSource Team Blog » Announcing SpringSource Tool Suite 2.0 — Tue, 17 Mar 2009 14:52:39 +0000

[...] I'd like to use this blog to introduce some of the new Spring development tools of STS 2.0. The new OSGi development tools have already been highlighted in an earlier blog. [...]

By: Jonas Partner » Blog Archive » Working with Maven and SpringSource dm Server

Sun, 08 Mar 2009 22:07:20 +0000

By: Jaro Kuruc

Jaro Kuruc — Fri, 06 Mar 2009 16:24:32 +0000

Fantastic! I can't wait

By: Christian Dupuis

Christian Dupuis — Fri, 06 Mar 2009 16:21:41 +0000

Jaro, glad that it is working for you now.

You are right that the tools could apply conventions for source and test folders. But as Rob mentioned the TEST.MF support is only the beginning. I'll add that to the project's backlog that we can track this requirement.

The problem that you are seeing (classes from source folder can see test dependencies) will go away in the next couple of weeks as the tools will start to detect this violation and report the problem.

Stay with us. There is lots of stuff to come in that area.

Christian

By: Jaro Kuruc

Jaro Kuruc — Fri, 06 Mar 2009 16:10:51 +0000

One disadvantage of using pom-driven dependencies is that m2eclipse adds dependency artifact as a whole to M2 classpath container (no excludes/includes filters). Because of this, it's possible to import package to my deployable class even if the imported package should have been available in tests only. I get an error only after I deploy such bundle to OSGi container.

Bundle classpath container nicely creates includes/excludes filters, so only imported packages are available in deployable classes.

But Bundle classpath container also allows me to use package from test dependency in deployable class as far as I am concerned. Any ideas how to prevent this?

Thanks for a brilliant tooling support.

Jaro