Announcement Announcement Module
Collapse
No announcement yet.
Binary dependencies, libraries and Eclipse Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Binary dependencies, libraries and Eclipse

    Hi all,

    I am using Spring DM server 1.0 and the Eclipse plugin, and searching for ideas to solve the following problem:
    In a project with lots of bundles and dependencies, it would be great when it is possible to use bundles as binary dependency, without the need to have all projects open in Eclipse. We used to do this by creating 'library bundles' (for example an orm bundle) which reexports its dependencies (for example all hibernate related jars). The concept of libraries as introduced with Spring DM seems to be a more elegant solution and solves lots of problems with split packages and conflicts (since all packages exported by the imported bundles are explicitly imported using Import-Package). I think (but maybe I am wrong, I am very open for suggestions) the ultimate goal is you have only the one or a few projects open on which you are working, the others are imported as binaries, with optional source attachment.

    Now the question is: is there a possibility to combine binary dependencies with the library concept? I have tried the following:
    • Export the bundle, leave the Import-Library headers in the manifest. I have placed the jar into the repository/bundles/usr directory. In Eclipse, I can use the bundle as required or imported bundle, but I do not see any bundles from the library in the Bundle Dependencies tree. At runtime, no bundles can resolve any classes from the library.
    • Same as above, but placed the jar in the pickup directory. Does not work, because the Eclipse plugin does not see the bundles in the pickup directory.
    With these two options, I am out of inspiration.. To summarize, I have the following questions:
    1. Am I on the right track? Is the binary depencies approach a good approach to eliminate time-consuming Eclipse workspace rebuilds and increase developer productivity, or are the better solutions (I am open for all suggestions)?
    2. Is there a possibility to use binary dependencies with Spring DM Server, when the Spring DM specific headers are used? If yes, where should I place these binaries?
    3. Should the repository contain only pure OSGi bundles (= no Spring specific headers)? If yes, what is the way to convert the Import-Library and Import-Bundle headers to Import-Package?
    4. Which bundles should be in the repository? Is it only for OSGi-fied third party jars, where should I copy my own binaries to?

    Thanks in advance for your time and responses.

    Regards,
    DaniŽl

  • #2
    Hi DaniŽl,

    Good questions!

    Originally posted by DaniŽl van 't Ooster View Post
    Am I on the right track? Is the binary depencies approach a good approach to eliminate time-consuming Eclipse workspace rebuilds and increase developer productivity, or are the better solutions (I am open for all suggestions)?
    Once you've finished development of one or more bundles, it's perfectly reasonable to add those bundles to the server's repository rather than relying upon having their projects open in Eclipse.
    Is there a possibility to use binary dependencies with Spring DM Server, when the Spring DM specific headers are used? If yes, where should I place these binaries?
    No, it's not. The dm Server-specific headers are transformed into OSGi-standard Import-Package entries during deployment. If a bundle's placed in the repository it won't go through this deployment process and, therefore, the header transformation won't occur.
    Should the repository contain only pure OSGi bundles (= no Spring specific headers)? If yes, what is the way to convert the Import-Library and Import-Bundle headers to Import-Package?
    Yes, the repository should only contain bundles with standard OSGi headers.

    Unfortunately there's currently no straightforward way to perform this conversion, although it is possible. If you deploy a bundle that uses Import-Bundle or Import-Library the server will transform the headers. So, you can deploy your bundle that uses Import-Bundle and Import-Library to perform the transformation and then copy the transformed manifest back into your bundle so that it's suitable for inclusion in the server's repository.

    One way to get at the transformed manifest is to look in the server's trace file. As part of the transformation processing the server traces the before and after views of the bundle's manifest. Take a look in serviceability/tracing/trace.log and you should be able to find the transformed manifest.

    Another way is to deploy your bundle, and to then use the OSGi telnet console to display the bundle's headers. Simply telnet into the console (port 2401 by default), use the ss (short status) command to list all of the bundles, and then headers <bundle-id> to display the manifest headers of the bundle in which you're interested.

    One note of caution: Import-Bundle and Import-Libary expand to an Import-Package of *every* package that's exported by the bundle(s). If your bundle makes extensive use of a particular bundle or library then this is a reasonable approach. However, if your bundle only makes limited use of a particular dependency you may want to consider narrowing things down by using Import-Package instead of Import-Bundle or Import-Bundle instead of Import-Library.

    Which bundles should be in the repository? Is it only for OSGi-fied third party jars, where should I copy my own binaries to?
    You can put any bundles you choose in the repository, with the restriction that they cannot use Import-Bundle and Import-Library. Deciding which of your own bundles should go in the repository is a matter of considering your applications' architecture and modularity. If you have one or more bundles which provide common functionality that you wish to share between applications then putting them in the server's repository definitely makes sense. If, on the other hand, a bundle is only of interest to one application, then it's typically more appropriate for that bundle to be deployed as part of the application itself, typically by including it in the application's PAR file.

    Hope this helps,
    Andy

    Comment


    • #3
      @Andy: thanks for your clarifications, I am now able to use bundles as binaries. I have put the library bundles in the repository, and deploy the bundles I am working on into the pickup or stage (via Eclipse plugin) directory.

      There is one remaining issue. Please consider the following (simplified) example: there are 3 bundles, say Bundle A, B and C. Bundle A and B contain some utility classes and can be found in the repository, Bundle B uses some packages from Bundle A. Bundle C imports packages from Bundle B. Now I want to some changes in Bundle A and Bundle C. Bundle C is opened in Eclipse.

      When I open bundle A and C in eclipse, drag them to the dm server, and start it, bundle C will not start because of it is missing Bundle B, which cannot start because it is missing Bundle A.

      I have found the following workaround
      • Remove Bundle A and B from the repository
      • Open Bundles A, B and C in Eclipse
      • Start the DM Server
      • Drag the bundles to the server, this should be in the correct order: A - B - C
      In this case, I did not have the intention to make any changes in bundle B, so I want to use bundle B as binary dependency. Is there a way to achieve this? Or should I look into other options (like building the binary with maven, and use the OSGi console to update the bundle)?

      regards,
      DaniŽl

      Comment

      Working...
      X