Gradle
  1. Gradle
  2. GRADLE-1107

OSGi instruction Include-Resource not working

    Details

    • Type: Bug Bug
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: 0.9.1
    • Fix Version/s: None

      Description

      According to the Bnd documentation an OSGi bundle is constructed from 3 different arguments:

      Export-Package
      Private-Package
      Include-Resource

      Using the Include-Resource instruction seems to have no effect on the resulting bundle.

      This might be an documentation issue. My understanding is that Bnd uses the Include-Resource instruction to add e.g additional Java archives to an OSGi bundle. If Gradle proposes a different approach to allow the same than it would be helpful if this could be documented.

        Issue Links

          Activity

          Hide
          Thomas Glaeser added a comment -

          After comparing different container apps, it is now clear to me that the initially proposed embedded* configurations would be the wrong approach

          Instead the following configurations would make sense in an OSGi world:

          • runtime extends compile
            • Dependencies declared under this configuration will be embedded into the OSGi bundle
          • providedRuntime extends providedCompile
            • Dependencies declared under this configuration will be provided by the OSGi Execution Environment/Target Platform
          • supplyRuntime extends supplyCompile
            • Dependencies declared under this configuration have to be supplied together with the OSGi bundle, e.g. in the form of an Eclipse feature

          I'm unsure about the naming for the supply* configurations. There might be another terminology matching this configuration better!?

          Show
          Thomas Glaeser added a comment - After comparing different container apps, it is now clear to me that the initially proposed embedded* configurations would be the wrong approach Instead the following configurations would make sense in an OSGi world: runtime extends compile Dependencies declared under this configuration will be embedded into the OSGi bundle providedRuntime extends providedCompile Dependencies declared under this configuration will be provided by the OSGi Execution Environment/Target Platform supplyRuntime extends supplyCompile Dependencies declared under this configuration have to be supplied together with the OSGi bundle, e.g. in the form of an Eclipse feature I'm unsure about the naming for the supply* configurations. There might be another terminology matching this configuration better!?
          Hide
          Thomas Glaeser added a comment -

          The issue was discussed via gradle-dev as well under subject "Gradle's OSGi plugin". Adam propose the following approach:

          1. Split the Java plugin into 3 pieces:
            • A java plugin which knows how to compile Java source into bytecode and how to run unit tests for it.
            • A jar-library plugin which knows how to build and publish a plain jar.
            • A java-runtime base plugin which provides the minimal pieces to define the runtime meta-data for the project: the set of classes, and the set of runtime dependencies.
              The jar-library plugin would:
            • Implicitly apply the java-runtime plugin.
            • Add the jar task.
            • Configure the publications so that the jar is published, along with the runtime dependencies in the dependency descriptor.
          2. Change the osgi plugin to:
            • Implicitly apply the java-runtime plugin. It would not apply the java plugin.
            • Add an osgiBundle task. It would not modify the jar task. It would create a separate bundle task.
            • Configure the publications so that the bundle is published.
            • Introduce the concept of target OSGi container.
          3. Change the war plugin to:
            • Implicitly apply the java-runtime plugin. It would not apply the java plugin.
            • Add the war task.
            • Configure the publications so that the war is published.
            • Introduce the concept of target web container.
            • We would remove the provided* configurations.
          4. Change the application plugin to:
            • Implicitly apply the java-runtime plugin. It would not apply the java plugin.
            • Add the distZip and install tasks.
            • Configure the publications so that the application zip is published.

          This approach allows:

          • Creating any combination of stand-alone jar, OSGi bundle and WAR.
          • Multiple jars, bundles or WARS, each targeting a different environment.
          • A project which contains no Java source code. For example, a parent project which aggregates the classes of its children. Or a Groovy/Scala/Clojure project.
          Show
          Thomas Glaeser added a comment - The issue was discussed via gradle-dev as well under subject "Gradle's OSGi plugin". Adam propose the following approach: Split the Java plugin into 3 pieces: A java plugin which knows how to compile Java source into bytecode and how to run unit tests for it. A jar-library plugin which knows how to build and publish a plain jar. A java-runtime base plugin which provides the minimal pieces to define the runtime meta-data for the project: the set of classes, and the set of runtime dependencies. The jar-library plugin would: Implicitly apply the java-runtime plugin. Add the jar task. Configure the publications so that the jar is published, along with the runtime dependencies in the dependency descriptor. Change the osgi plugin to: Implicitly apply the java-runtime plugin. It would not apply the java plugin. Add an osgiBundle task. It would not modify the jar task. It would create a separate bundle task. Configure the publications so that the bundle is published. Introduce the concept of target OSGi container. Change the war plugin to: Implicitly apply the java-runtime plugin. It would not apply the java plugin. Add the war task. Configure the publications so that the war is published. Introduce the concept of target web container. We would remove the provided* configurations. Change the application plugin to: Implicitly apply the java-runtime plugin. It would not apply the java plugin. Add the distZip and install tasks. Configure the publications so that the application zip is published. This approach allows: Creating any combination of stand-alone jar, OSGi bundle and WAR. Multiple jars, bundles or WARS, each targeting a different environment. A project which contains no Java source code. For example, a parent project which aggregates the classes of its children. Or a Groovy/Scala/Clojure project.
          Hide
          Thomas Glaeser added a comment -

          I like Adam's proposal a lot. The questions is still how to describe your target environment - what is provided by the container, what needs to be supplied to the container when deploying into it, and what will be available embedded only!?

          Show
          Thomas Glaeser added a comment - I like Adam's proposal a lot. The questions is still how to describe your target environment - what is provided by the container, what needs to be supplied to the container when deploying into it, and what will be available embedded only!?
          Hide
          Todor Boev added a comment -

          I am adding additional comments prompted by our use of the OSGi gradle plugin:

          Currently BND is used only to calculate the bundle manifest. This means that none of BND powerful packaging capabilities are used.

          Here are some use-cases:

          • Use the full power of 'Export-Package' and 'Private-Package' to package an arbitrary set of classes from the entire classpath into a new bundle. This can be used to bundelize third party libraries or create bundles that mix parts of the classpath with the local classes. I is also possible to choose whether to run on the entire classpath or only on the set of classes produced by the current module. The new Maven BND plugin supports this option.
          • Use Include-Resource to do the same as Private-Package but on resources. Here we an include *.jar resources in "inline" mode. This will unpackage a third party library into the bundle. Than the normal manifest calculations will be executed. This is also a powerful way to bundelize third party libraries.
          • Use "-wab" and "-wablib" to build web bundles. Here BND will move the classes to "WEB-INF/classes" the libraries to "WEB-INF/lib", adjust the Bundle-Classpath header to include the classes and the libraries. Finally it will move the static resources to the root of the bundle. Doing this in an easy way is important for our plans to build web apps on top of OSGi.

          In short BND is not a manifest calculator but a powerful bundle building tool and it is a good idea for us to support it to it's full extent.

          Show
          Todor Boev added a comment - I am adding additional comments prompted by our use of the OSGi gradle plugin: Currently BND is used only to calculate the bundle manifest. This means that none of BND powerful packaging capabilities are used. Here are some use-cases: Use the full power of 'Export-Package' and 'Private-Package' to package an arbitrary set of classes from the entire classpath into a new bundle. This can be used to bundelize third party libraries or create bundles that mix parts of the classpath with the local classes. I is also possible to choose whether to run on the entire classpath or only on the set of classes produced by the current module. The new Maven BND plugin supports this option. Use Include-Resource to do the same as Private-Package but on resources. Here we an include *.jar resources in "inline" mode. This will unpackage a third party library into the bundle. Than the normal manifest calculations will be executed. This is also a powerful way to bundelize third party libraries. Use "-wab" and "-wablib" to build web bundles. Here BND will move the classes to "WEB-INF/classes" the libraries to "WEB-INF/lib", adjust the Bundle-Classpath header to include the classes and the libraries. Finally it will move the static resources to the root of the bundle. Doing this in an easy way is important for our plans to build web apps on top of OSGi. In short BND is not a manifest calculator but a powerful bundle building tool and it is a good idea for us to support it to it's full extent.
          Hide
          Szczepan Faber added a comment -

          The goals and potential implementation plan is described at the thread: http://gradle.1045684.n5.nabble.com/Gradle-s-OSGi-plugin-td3408224.html

          Show
          Szczepan Faber added a comment - The goals and potential implementation plan is described at the thread: http://gradle.1045684.n5.nabble.com/Gradle-s-OSGi-plugin-td3408224.html

            People

            • Assignee:
              Unassigned
              Reporter:
              Thomas Glaeser
            • Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Development