On Tue, Mar 8, 2011 at 8:16 PM, Glaeser, Thomas <[email protected]> wrote:
> <TG>Well, I commented on your example. In Gradle, if you declare a > project dependency you own the project; otherwise you would declare a > dependency against a module or artifact. If you want to use external > modules in your OSGi application you either find an OSGi-aware version > of it or bundleize it yourself. Simply embedding everything that is not > available as a bundle is not a very OSGi like approach.</TG> Uhhh.... Why do you think Bundle-ClassPath exists? Why do you think that the original concept of deployment was 1Bundle==1Application? Just because Eclipse-based apps are 2000 bundles, doesn't mean it is "right way" to do it. > Simple question; Do you agree that building a WAB which is also a > deployable WAR, as Kriens suggest on http://www.aqute.biz/Bnd/Format > (subheading Web Archive Bundles), is a desirable option? If not, we can > stop this discussion. > > <TG>Absolutely; if I recall correctly then I proposed the WAB use case > as the perfect sample as it has all the requirements of an OSGi > container application. However the new osgi-plugin MUST support all > other target containers equally, being them more simple or more > complicated.</TG> Ok. So, what is WAB? It is NOT a container contract as such. On the classloading side of things, it is nothing more than regular OSGi, and the rest is about allowing various resources into the bundle. It is possible to lay out the jar like a WAR, which I think is totally Ok. So, I still maintain that some type of 'embed jars' and 'embed exploded' should exist (just like the Maven bundle plugin), and that if I signal 'wab' that a reasonable default is provided (for instance, embed all non-OSGified runtime dependencies). 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
