The osgi plugin does not address your use case currently. It does only generate the manifest. We will address this issue for 1.0. The workaround you have at the moment is to use the bnd ant task and then to merge the generated manifest and other files into the jar task.

This is actually only a problem if the resource is a Java ARchive that shall get embedded into the OSGi bundle. Simple resources can just be added to the production resources source set and will be automatically added to the OSGi bundle from there.

For JAR resources two things have to happen to get this working.

• Copy the JAR resources under the classesDir, e.g. classesDir/lib/my-resource.jar
• Add the previously copied JAR resources to the Bundle-ClassPath instruction, e.g. .,lib/my-resource.jar

In order to separate the embedded JARs from the provided once I'm proposing the addition of two more configurations to the OSGi Plugin:

• embeddedCompile
• embeddedRuntime extends embeddedCompile

My understanding is that the runtime configuration should not be extended by embeddedRuntime, only compile should be extended by embeddedCompile as the associated artifacts are embedded and only available via the bundle classpath.

If interested, I can provide the code for this change. Also note that AFAIK this change will require the OSGi plugin to directly apply the Java plugin.

In contrast to the POJO world where the runtime configuration is just an ordered list of containers, in OSGi, the containers from the runtime classpath itself can be ordered lists of container paths. The effective bundle classpath will be calculated based on headers Bundle-Classpath and Fragment-Host. Therefore it is probably required to introduce a new osgiRuntime configuration.

In a scenario where all of the containers from the effective bundle classpath are Java ARchives, the new osgiRuntime configuration could be constructed from the entries found in configurations runtime and embeddedRuntime.

In a scenario where the effective bundle classpath contains Java Package entries, the osgiRuntime configuration would have to become Java Package sensitive.

Consequences of the previously said are that additional bundleRuntime* configurations are needed beyond the osgiRuntime configuration.

In a POJO world:

Configuration embeddedCompile SHALL NOT be part of the runtime configuration:

• runtime.extendsFrom( compile - embeddedCompile)

This has a side effect on the IDE plugins as the libraries from the embeddedCompile configuration have to be available in the IDE

In OSGi:

The OSGi plugin needs to dynamically create additional bundleRuntime* configurations:

• if ( Fragment-Host.exists())
  -> do not create new bundleRuntime configuration nor add the bundle to the osgiRuntime configuration; remember Fragment-Host
• else if ( !Bundle-Classpath.exists())
  -> no special handling needed, bundle will be added to osgiRuntime configuration
• else if ( !Fragment-Host.exists() && Bundle-Classpath.exists())
  -> calculate new bundleRuntime$projectName configuration and extend the osgiRuntime configuration from it

Thanks a lot for explaining the issue. One generic improvement for this will be our upcoming dependency DSL which enables to easily subtract, filter, ... dependency configurations. We will also add some other constructs that might provide alternative to using configurations for modeling this. Kind of similar to the 'provided' problem of container apps.

It appears to me that we also need configurations

• providedCompile
• providedRuntime extends providedCompile

representing the OSGi Execution Environment.

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!?

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.

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!?

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.

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

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.