Spring Roo
  1. Spring Roo
  2. ROO-1937

Add new option to add-on creator to facilitate creation of wrapped bundles (such as JDBC drivers)

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 1.1.1.RELEASE
    • Component/s: @ CORE
    • Labels:
      None

      Description

      Add new option to add-on creator to facilitate creation of wrapped bundles (such as JDBC drivers).

        Issue Links

          Activity

          Hide
          Stefan Schmidt added a comment -

          Complete with commit 91832b49d16361650d291e26699cd7d9401485bc.

          Arbitrary bundles can now be wrapped with the 'addon create wrapper' command. For example to create a wrapper for the Postgres JDBC driver this command will work:

          addon create wrapper --topLevelPackage com.foo.bar.wrapper --projectName spring-roo-postgres-wrapper --artifactId postgresql --groupId postgresql --version 9.0-801.jdbc3 --description "Postgres #jdbcdriver driverclass:org.postgresql.Driver." --licenseUrl http://jdbc.postgresql.org/license.html --docUrl http://jdbc.postgresql.org/ --vendorName "The PostgreSQL Global Development Group"
          

          The generated pom.xml is (similar to the other 'addon create' commands) optimized for Google code hosting and can therefore be easily deployed using the 'mvn deploy' command.

          Show
          Stefan Schmidt added a comment - Complete with commit 91832b49d16361650d291e26699cd7d9401485bc. Arbitrary bundles can now be wrapped with the 'addon create wrapper' command. For example to create a wrapper for the Postgres JDBC driver this command will work: addon create wrapper --topLevelPackage com.foo.bar.wrapper --projectName spring-roo-postgres-wrapper --artifactId postgresql --groupId postgresql --version 9.0-801.jdbc3 --description "Postgres #jdbcdriver driverclass:org.postgresql.Driver." --licenseUrl http: //jdbc.postgresql.org/license.html --docUrl http://jdbc.postgresql.org/ --vendorName "The PostgreSQL Global Development Group" The generated pom.xml is (similar to the other 'addon create' commands) optimized for Google code hosting and can therefore be easily deployed using the 'mvn deploy' command.
          Hide
          Ben Alex added a comment -

          For context, the wrapper will turn a non-OSGi JAR into an OSGi-enabled JAR. Specifically, an automatic static analysis is undertaken of the classes in the input JAR and a manfiest is created in the resulting output JAR. The output JAR is then usable in Roo or other OSGi containers. Occasionally you'll need to tweak the maven-bundle-plugin instructions in pom.xml. For non-trivial examples of this, check Roo out of Git and review the items we're wrapping in the /wrapping directory. Most of the time, though, the automatic static analysis is sufficient and it will simply work without maven-bundle-plugin tweaks.

          Note the --artifactId, --groupId and --version given in the command represents the "input" non-OSGi JAR and should identify that JAR in your local Maven repository. When you "mvn deploy" the standard Maven behavior of attempting an automatic downloaded from a remote Maven repository (such as Maven Central) if not already local will occur. Obviously only items in remote Maven repositories will automatically download.

          If you "mvn deploy", by default the wrapped JAR will be placed on Google Code. You can email the OBR repository.xml URL of your Google Code project to s2-roobot@vmware.com and it will be automatically indexed and subsequently appear in the "addon search", "addon install" etc commands. This is the easiest way to make a wrapped JAR available to all Roo users. See the Spring Roo Reference Guide for more details on add-on distribution and RooBot.

          Please check the license carefully of any items you wrap. Do not "mvn deploy" items to Google Code or other public locations where doing so would be violating their licenses. If you do not "mvn deploy", you may use "mvn install" to create a local OSGi-enabled JAR on your machine (which is installed into your local Maven repository), and from there you can load that JAR in your Roo installation using the "osgi start" command. A further alternative is to edit the pom.xml of the created project and configure it to deploy to a web server within your organisation (if permitted by the license). If you do this, you can then share the organisation's web server OBR repository.xml URL with your colleagues and then use Roo's "osgi obr url add" command to add that URL to their environments. Once this is completed, the "osgi obr start" command will work and enable you to start the bundles defined in that repository.xml. This is the generally suggested approach if you have multiple libraries to wrap inside your organisation that you cannot share publicly for some reason (licensing, confidentiality, liability etc). Of course another alternative is to copy the JAR you produced using "mvn install" to an organisational web server and simply give internal people fully-qualified "osgi start" commands containing that URL. These techniques mean you need not have everyone in your organisation wrapping the same libraries yet you can share the results of someone having performed the wrapping.

          Naturally if a wrapped library is open source, please wrap it and use "mvn deploy" to deploy it to the default Google Code repository to share it with the wider community via the RooBot mechanism mentioned earlier. This is far easier as the "addon" commands automate searching and installation, plus inbuilt features such as Roo shell's unknown command resolver and Roo's JDBC acquisition module will be able to automate the installation of such add-ons.

          Show
          Ben Alex added a comment - For context, the wrapper will turn a non-OSGi JAR into an OSGi-enabled JAR. Specifically, an automatic static analysis is undertaken of the classes in the input JAR and a manfiest is created in the resulting output JAR. The output JAR is then usable in Roo or other OSGi containers. Occasionally you'll need to tweak the maven-bundle-plugin instructions in pom.xml. For non-trivial examples of this, check Roo out of Git and review the items we're wrapping in the /wrapping directory. Most of the time, though, the automatic static analysis is sufficient and it will simply work without maven-bundle-plugin tweaks. Note the --artifactId, --groupId and --version given in the command represents the "input" non-OSGi JAR and should identify that JAR in your local Maven repository. When you "mvn deploy" the standard Maven behavior of attempting an automatic downloaded from a remote Maven repository (such as Maven Central) if not already local will occur. Obviously only items in remote Maven repositories will automatically download. If you "mvn deploy", by default the wrapped JAR will be placed on Google Code. You can email the OBR repository.xml URL of your Google Code project to s2-roobot@vmware.com and it will be automatically indexed and subsequently appear in the "addon search", "addon install" etc commands. This is the easiest way to make a wrapped JAR available to all Roo users. See the Spring Roo Reference Guide for more details on add-on distribution and RooBot. Please check the license carefully of any items you wrap. Do not "mvn deploy" items to Google Code or other public locations where doing so would be violating their licenses. If you do not "mvn deploy", you may use "mvn install" to create a local OSGi-enabled JAR on your machine (which is installed into your local Maven repository), and from there you can load that JAR in your Roo installation using the "osgi start" command. A further alternative is to edit the pom.xml of the created project and configure it to deploy to a web server within your organisation (if permitted by the license). If you do this, you can then share the organisation's web server OBR repository.xml URL with your colleagues and then use Roo's "osgi obr url add" command to add that URL to their environments. Once this is completed, the "osgi obr start" command will work and enable you to start the bundles defined in that repository.xml. This is the generally suggested approach if you have multiple libraries to wrap inside your organisation that you cannot share publicly for some reason (licensing, confidentiality, liability etc). Of course another alternative is to copy the JAR you produced using "mvn install" to an organisational web server and simply give internal people fully-qualified "osgi start" commands containing that URL. These techniques mean you need not have everyone in your organisation wrapping the same libraries yet you can share the results of someone having performed the wrapping. Naturally if a wrapped library is open source, please wrap it and use "mvn deploy" to deploy it to the default Google Code repository to share it with the wider community via the RooBot mechanism mentioned earlier. This is far easier as the "addon" commands automate searching and installation, plus inbuilt features such as Roo shell's unknown command resolver and Roo's JDBC acquisition module will be able to automate the installation of such add-ons.
          Hide
          Winarto added a comment -

          I tried to wrap Oracle JDBC Driver ojdbc14.jar version 10.2.0.2 using "addon create wrapper". When calling osgi start --url <filename> i got "Unresolved constraint in bundle com.<mycompany>.xxx: package; (package=javax.resource).

          Now everytime I start roo, this error always occurs.

          Show
          Winarto added a comment - I tried to wrap Oracle JDBC Driver ojdbc14.jar version 10.2.0.2 using "addon create wrapper". When calling osgi start --url <filename> i got "Unresolved constraint in bundle com.<mycompany>.xxx: package; (package=javax.resource). Now everytime I start roo, this error always occurs.

            People

            • Assignee:
              Stefan Schmidt
              Reporter:
              Stefan Schmidt
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: