Spring Roo
  1. Spring Roo
  2. ROO-1052

Develop OSGi Projects Applications with Spring Roo

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: BUILD
    • Labels:
      None

      Description

      I think is very useful if I can develop OSGi Components using ROO.

        Issue Links

          Activity

          Hide
          Ben Alex added a comment -

          Spring Roo 1.0.0 emitted OSGi-compliant applications. We used the SpringSource Enterprise Bundle Repository (EBR) to access OSGi-enabled bundles (JARs) with correct manifests etc. Tasks such as ROO-138 enabled use of the SpringSource Bundlor utility to help create compliant manifests for Roo-based projects.

          After considerable community demand (as shown in ROO-713 and ROO-973), in Spring Roo 1.1.0 we shifted to using Maven Central as the default source of JARs for Roo-based projects. In doing so many of the Maven Central-hosted dependencies needed to build an OSGi-compliant application were no longer valid bundles.

          Quite paradoxically given the above changes, in Roo 1.1.0 we changed Roo itself to start using OSGi as its foundation (see ROO-728). I actually quite like OSGi and it's a perfect fit for Roo given its modularity requirements. In Roo's case we established a JAR wrapping model (see ROO-977) to handle acquiring OSGi compliant bundles for the few external JARs that Roo and its major add-ons require. But for an enterprise application there are too many non-bundle JARs sourced from Maven Central and a wrapping model therefore isn't particularly feasible.

          I'm going to leave this task open to see how many votes it receives. If a large number of votes are forthcoming we could probably produce some documentation explaining how to turn a Roo project into an OSGi-compliant bundle, which JPA implementations are available in that form and so on. But it's worth noting that third-party Roo add-ons in particular will likely use non-compliant JARs (ie not bundles) and this will break efforts to make OSGi applications via Roo.

          People interested in using Roo to build OSGi-compliant applications are encouraged to document in the comments of this task the bundles they used and which server they deployed to. This will help others, plus allow us to see the gap in missing bundles.

          Show
          Ben Alex added a comment - Spring Roo 1.0.0 emitted OSGi-compliant applications. We used the SpringSource Enterprise Bundle Repository (EBR) to access OSGi-enabled bundles (JARs) with correct manifests etc. Tasks such as ROO-138 enabled use of the SpringSource Bundlor utility to help create compliant manifests for Roo-based projects. After considerable community demand (as shown in ROO-713 and ROO-973 ), in Spring Roo 1.1.0 we shifted to using Maven Central as the default source of JARs for Roo-based projects. In doing so many of the Maven Central-hosted dependencies needed to build an OSGi-compliant application were no longer valid bundles. Quite paradoxically given the above changes, in Roo 1.1.0 we changed Roo itself to start using OSGi as its foundation (see ROO-728 ). I actually quite like OSGi and it's a perfect fit for Roo given its modularity requirements. In Roo's case we established a JAR wrapping model (see ROO-977 ) to handle acquiring OSGi compliant bundles for the few external JARs that Roo and its major add-ons require. But for an enterprise application there are too many non-bundle JARs sourced from Maven Central and a wrapping model therefore isn't particularly feasible. I'm going to leave this task open to see how many votes it receives. If a large number of votes are forthcoming we could probably produce some documentation explaining how to turn a Roo project into an OSGi-compliant bundle, which JPA implementations are available in that form and so on. But it's worth noting that third-party Roo add-ons in particular will likely use non-compliant JARs (ie not bundles) and this will break efforts to make OSGi applications via Roo. People interested in using Roo to build OSGi-compliant applications are encouraged to document in the comments of this task the bundles they used and which server they deployed to. This will help others, plus allow us to see the gap in missing bundles.
          Hide
          Alex Blewitt added a comment -

          I'm interested to know what Maven-Central hosted dependencies don't have OSGi metadata any more. Whilst it will still be possible to have some of them, many bundles are now OSGi compliant - though it might restrict the choice of providers which support it.

          I don't think it should necessarily be the default, but I do think it should be attempted if a project --osgi or similar was set. (Doing this after the JPA providers have standardised on the OSGi enterprise group would probably make sense)

          Show
          Alex Blewitt added a comment - I'm interested to know what Maven-Central hosted dependencies don't have OSGi metadata any more. Whilst it will still be possible to have some of them, many bundles are now OSGi compliant - though it might restrict the choice of providers which support it. I don't think it should necessarily be the default, but I do think it should be attempted if a project --osgi or similar was set. (Doing this after the JPA providers have standardised on the OSGi enterprise group would probably make sense)
          Hide
          Mirko Jahn added a comment -

          Just my 2 cents, but maybe a flag in the roo add-ons stating wether they provide OSGi compliant enhancements would help to sort things out. Once a project indicates that it is producing OSGi compatible artifacts only OSGi compatible add-ons are usable/enabled by default. This could enable a more smooth migration path. I'd really love to have OSGi support down the line in order to be able to use roo more extensively.

          Show
          Mirko Jahn added a comment - Just my 2 cents, but maybe a flag in the roo add-ons stating wether they provide OSGi compliant enhancements would help to sort things out. Once a project indicates that it is producing OSGi compatible artifacts only OSGi compatible add-ons are usable/enabled by default. This could enable a more smooth migration path. I'd really love to have OSGi support down the line in order to be able to use roo more extensively.
          Hide
          aappddeevv added a comment -

          Is there a roo switch or option that allows EBR to be used for user bundles versus maven central?

          Is it as simple as changing the dependencies in the pom, perhaps manually?

          Show
          aappddeevv added a comment - Is there a roo switch or option that allows EBR to be used for user bundles versus maven central? Is it as simple as changing the dependencies in the pom, perhaps manually?
          Hide
          chris snow added a comment -

          Eclipse Scout (http://www.eclipse.org/scout/) is a similar concept to roo that generates osgi projects. Currently only swing and swt clients are supported, but the next release will provide a web interface too. It may be worth a look if you can't wait for Roo OSGi support.

          Show
          chris snow added a comment - Eclipse Scout ( http://www.eclipse.org/scout/ ) is a similar concept to roo that generates osgi projects. Currently only swing and swt clients are supported, but the next release will provide a web interface too. It may be worth a look if you can't wait for Roo OSGi support.
          Hide
          Andrew Swan added a comment -

          Roo addons are OSGi bundles, and Roo has commands for generating various types of addons (e.g. "addon create simple"). So while it's not a complete solution (for example there's no round-tripping), you can at least use Roo to create a Maven project that generates an OSGi bundle.

          Show
          Andrew Swan added a comment - Roo addons are OSGi bundles, and Roo has commands for generating various types of addons (e.g. " addon create simple "). So while it's not a complete solution (for example there's no round-tripping), you can at least use Roo to create a Maven project that generates an OSGi bundle.

            People

            • Assignee:
              Unassigned
              Reporter:
              Ed Pichler
            • Votes:
              28 Vote for this issue
              Watchers:
              23 Start watching this issue

              Dates

              • Created:
                Updated: