On Fri, Mar 4, 2011 at 8:01 AM, Glaeser, Thomas <[email protected]> wrote: > So for now let's consider these two runtime configurations only: > > (1) runtime > (2) providedRuntime > > These configurations exist already in Gradle and Maven and we do not want to > redefine them.
Good. > The two configurations are required for building Web Archives (WAR). Please > see the Gradle WAR Plugin documentation for their meaning. What we can take > from here is that the libraries from the runtime configuration are embedded > into the WAR while the dependencies from the providedRuntime configuration > are provided by the hosting container. > > Now, how does this all map to Web Application Bundle (WAB)? Please see the > BND documentation. > > So someone who used the Gradle War Plugin should get a valid WAB by simply > also applying the OSGi Plugin. In my opinion this would be the first use > case the new OSGi Plugin needs to pass. If runtime implies 'embedded', then we *must* have a different produced artifact from the OSGi project. Why? As I explained; Many projects, Qi4j included, are not OSGi specific, only OSGi-aware. I.e. their primary use is 'normal', but they provide the Bundle Manifest entries so they can be loaded in OSGi. It is *not* reasonable to bug these projects down with having all their dependencies embedded in the output artifact. But, as I discovered for Qi4j, some dependencies are not OSGi-aware, and to allow deployment of "Qi4j bundles", I either need to OSGify those dependencies (hard work) or provide the runtime configuration embedded in each Qi4j library. So that requirement contradicts the previous paragraph. Hence, I am leaning very heavily towards generation of separate artifacts for the "normal jar" vs "bundle jar". Makes sense? Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
