Blogs

SpringSource Blog

OSGi Development Tools in STS 2.0

Christian Dupuis

Yesterday we published a final release candidate build of the upcoming SpringSource Tool Suite version 2.0. The RC build is available for Windows, Mac OS X and Linux from the STS product page.

STS 2.0 is equipped with new productivity tools for developing Spring applications, like Quick Fixes, as-you-type validation and correction, project and bean creation wizards as well as a Visual Spring Configuration Editor and more. Stay tuned for more information on these new features.

Additionally STS 2.0 comes with tools for OSGi-based application development that experienced as well as new adopters of OSGi might find interesting. I'd like to use this blog to briefly introduce those features.

Existing Tools

To recap let's start with an overview of what OSGi development tools have been available since the launch of the SpringSource dm Server with STS and the open-source dm Server Tools:

  • dm Server Integration: STS provides integration for dm Server into Eclipse WTP that lets you manage the life-cycle of integrated dm Server instances (start/stop/debug) as well as to deploy OSGi bundles, PARs and traditional JEE WARs. The dm Server integration also transparently handles refresh and update operations of deployed artifacts if code has been changed by the user.
  • Project Wizards: To create OSGi bundle and PAR projects STS provides two project wizards that automatically set up the project structure and all the required Eclipse meta data. For traditional WARs the WTP Dynamic Web Project wizard can still be used.
  • Manifest Editing and Validation: STS provides content assist, hyperlinking and validation for MANIFEST.MF files to make the task of managing OSGi meta data as easy as possible. Common problems can be automatically resolved by using the integrated Quick Fixes (e.g. download missing dependency or correct version range).
  • Classpath Management: STS will pick up the OSGi dependency meta data from the MANIFEST.MF and create a classpath container with correct visibility rules applied. The dependencies are being resolved against the local dm Server bundle and library repository. Test-only dependencies can be added to a file called TEST.MF in the META-INF folder of the test source folder.
  • Repository Browser: STS integrates the SpringSource Enterprise Bundle Repository to provide integrated access to the available enterprise libraries. This makes it really easy to download and install a third-party dependency bundles.

Repository Browser

New in STS 2.0

STS 2.0 provides new tools to analyze bundles and visualize their dependencies based on Import-/Export-Package relationships and Service consumption. The accessible information is similar to what users commonly get in textual form from the admin shell of an OSGi runtime, e.g. the Equinox Console. But the benefit of these new tools is that you get relevant information integrated in your development environment and have visual tools at hand to navigate and check your bundle meta data and wiring; there is no need to leave the IDE to open up a telnet session.

The following screenshot (click to enlarge) shows the Bundle Overview page of the Server Editor. This page lists all installed bundles and provides access to the bundle's meta data in form of the MANIFEST as well as all wiring information accessible from the OSGi runtime. Dedicated sections show exported and imported packages and their respective consumers and providers as well as registered OSGi services including their properties and their consumers.

Bundle Overview

The displayed information is retrieved from the running dm Server and therefore immediately reflects changes if bundles are installed, stopped or updated. Navigating the dependencies of a particular bundle in the Bundle Overview or the Equinox Console for that matter can get quite cumbersome as both do not visualize the entire dependency graph. So in order to analyze wiring problems the user needs to iterate from one bundle to the next.

The new Bundle Dependency Graph makes this task very easy by allowing you to visually navigate the dependency graph. The Graph can show package or service dependencies. Additionally the maximum depth of dependencies displayed in the graph may be changed.

I would recommend to try this out yourself as it is much more fun to see the Graph in action as you can imagine from a static screenshot.

Bundle Dependency Graph

Last but not least some users like to stay in the environment they are used to. This is why we also integrated a textual console into STS. The Server Console (see below) supports the very same commands as the Equinox console but provides command completion and command history on top.

Server Console

Conclusion

The highlighted features are not the only additions to STS 2.0 but should provide an insight of what STS has to offer for OSGi development. We will publish more information covering other feature areas as we get closer to GA later this month.

Nevertheless this is the right time to give the STS 2.0 RC a try with your Spring or OSGi project and let us know what you think. Please report any issue you may find in the product's JIRA or the community forums.

Similar Posts

Share this Post
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • DZone
  • LinkedIn
  • Slashdot
  • Technorati
  • Twitter
 

10 responses


  1. Christian,

    I'm glad to see the dm Server tooling coming along so well. The navigable, visual Bundle Dependency Graph is truly a step forward compared to the Equinox console for analyzing live wirings. Support for TEST.MF is also a nice touch!

    Any word on an ETA for more testing support? ;)

    cheers,

    Sam


  2. Hi Christian

    Could you explain how support for TEST.MF file is supposed to work? I'm trying to add TEST.MF file to my src/test/resources/META-INF folder (src/test/resources is one of my 4 source folders) but it seems this file is simply ignored. Only dependencies from src/main/resources/META-INF/MANIFEST.MF are added to 'Bundle Dependencies' node.

    Jaro


  3. Jaro,

    in order to let the tools pick up the TEST.MF from your src/test/resources source folder you need to mark that folder as a "Test Source Folder". You can do that from the Project Preferences -> Spring -> Java Test Folders. Once you've selected the src/test/resources folder you should see the TEST.MF being picked up and dependencies from that manifest appearing the Bundle Dependencies classpath container.

    HTH

    Christian


  4. Fantastic! It works after marking the folder as a test folder.

    Any reason why not to use sensible defaults a.k.a. maven folder structure (src/main/* for deployable sources and src/test/* for tests) which could be changed manually if not relevant? Can't imagine anyone using src/test folder as a source folder for deployable classes/resources.

    Now my only problem is how to make SpringSource Tooling live together with m2eclipse effectivelly. As I don't want to have dependencies defined twice, at the moment I am generating MANIFEST.MF file using maven-bundle-plugin. Obviously, this works for compile time dependencies only and not test dependencies.

    I know you guys are working on bundlor maven plugin, but I am lacking any documentation on how to use it. Would it be possible to use it to generate TEST.MF file as well? Thanks for any suggestions.

    Jaro


  5. @Sam – Test support is on our backlog. We'll be releasing our integration test preview in the next couple of weeks and we hope to provide super Eclipse tooling for that as soon as possible after that.

    @Jaro – We'll be releasing the Maven/Bundlor plugin around the same time as the test tool. You can expect this to work so that the Maven pom will be your only dependency file format – the manifest will be generated by bundlor. If you prefer to have manifest-driven builds, we are still working on that – TEST.MF is only the first step on the journey there. If you want to have pom-driven, then I think we'll have something that will meet most of your needs in the next few weeks

    Rob


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


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


  8. Fantastic! I can't wait :)


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


  10. I am very interested in the Bundle Denpendency Graph, that is an amazing feature.
    I have downloaded the latest version of STS, which is springsource-tool-suite-2.6.1.SR1-e3.6.2-win32.zip, but I cannot find where the dependency graph is, can you tell me?
    Thank you!

8 trackbacks

Leave a Reply