I agree with Guillaume that trying to extend karaf to take over geronimo, servicemix, and deal with all non-osgi artifacts is not a very good idea. (yes, I'm exaggerating a little bit).
One idea I had working on the kar packaging was to include bnd instructions in the pom so that non-bundles included in a kar could have bnd run properly on them so you could get more reasonable results than with the wrap deployer. However I am not at all convinced that this provides any significant advantages over separate "bundleize" projects like servicemix and geronimo have, and it certainly has the obvious disadvantage that the bundleized jar is not widely accessible. BTW geronimo 3 currently can deploy javaee artifacts as bundles, although we are still including a lot of not-very-osgi-friendly infrastructure (which we hope will be gone by the time we release). thanks david jencks On Feb 28, 2011, at 11:35 AM, Guillaume Nodet wrote: > On Mon, Feb 28, 2011 at 20:21, karafman <[email protected]> wrote: >> >> Guillaume Nodet wrote: >>> >>> On Mon, Feb 28, 2011 at 19:36, karafman <[email protected]> wrote: >>>> We've been talking in IRC about new features we could add to Karaf to >>>> make it >>>> more accessable to development teams who don't know much about OSGi. >>>> Things >>>> that would decrease the learning curve. This thread's intent is to >>>> gather >>>> suggestions, and to give feedback to them. >>>> >>>> To start the thread: >>>> >>>> 1) Inspect each bundle on deployment for the MANIFEST.MF header >>>> "Bundle-ManifestVersion", and then automatically wrap ones missing that >>>> header. >>> >>> The wrap deployer does that if you drop a jar in the deploy folder. >>> >>>> 2) Have Karaf look at each .jar or .ear being deployed for a >>>> "Bundle-Version" in its Manifest.MF file, and if it doesn't have it, look >>>> for a ./lib directory, wrapping and deploying everything in that >>>> directory, >>>> then removing it from the original .jar file, then wrapping the original >>>> .jar file, and finally deploying and starting the original. This >>>> wouldn't >>>> configure services, but it would provide a strong starting point for >>>> teams >>>> moving from JEE to Karaf. >>> >>> Wouldn't it be easier to use a Bundle-ClassPath instead ? That's what >>> is done when you drop a war in the deploy folder. >>> >>>> 3) Have karaf look in META-INF/spring and OSGI-INF for all xml files, and >>>> then automatically add any packages referenced there to the >>>> Import-Package >>>> portion of the MANIFEST.MF file. This is probably a bnd change, but >>>> still >>>> would be a nice-to-have. >>> >>> That is be done already either using the maven-bundle-plugin or the >>> blueprint/spring deployer from the deploy folder. >>> >>>> >>>> ----- >>>> Karafman >>>> Slayer of the JEE >>>> Pounder of the Perl Programmer >>>> >>>> -- >>>> View this message in context: >>>> http://karaf.922171.n3.nabble.com/Suggested-3-x-x-functionality-tp2597220p2597220.html >>>> Sent from the Karaf - Dev mailing list archive at Nabble.com. >>>> >>> >> >> 1) Ahh, this suggestion was made for when you deploy a bundle from the >> console. > > Yeah, the console is quite limited for provisioning. > >> 2) Sure, Bundle-Classpath would be a good idea. The point is to make it >> easier for folks to take existing .jar files and simply drop them into >> Karaf, with Karaf doing most of the heavy lifting. > > Jar containing other jars aren't really supported by any classloader. > This is a pure JEE packaging afaik, and I'm quite sure Geronimo will > provide full support for EARs. ServiceMix provides support for JBI > artifacts (which are also zip inside zips) and Pax-Web for wars. What > kind of packaging are you thinking about exactly ? > >> 3) This suggestion is for when you are using the console to deploy .jar >> files. > > You can't really deploy an spring or xml blueprint file from the > console ,can you ? > So I suppose you deploy a jar / bundle and the maven-bundle-plugin > should have done its work before that. > >> >> Honestly, I don't really use the deploy mechanism, as I've been building up >> my provisioning file by hand, and have gotten into the habit of deploying >> through the console. >> >> For the second suggestion, I can definately see where you'd want that >> functionality from the deploy folder also. This is because the second >> suggestion assumes a developer with limited knowledge of Karaf who is simply >> looking for a tool that provides an easy start to migrating existing >> functionality into OSGi. > > Pay attention though. If you deploy jars which aren't nice OSGi > bundles using the wrap url handler, or automatic wrapping, you will > remove a lot of the goodness provided by OSGi, such as the ability to > support multiple versions of the same libraries / jars / packages > etc... So you get back to a world where you need to tighly control > and align all your dependencies. > I've always advocated the use of the wrap url handler at development / > prototype time, but not in production, so I'm not really at ease with > adding too much things to hide the osgi metadata (at least in a bad > way), because I fear it'll backfire at some point. > It's fine to hide OSGi when you have a different packaging (war, jbi, > ear), but trying to hide osgi without defining clear classloader rules > / boundaries will only lead to problems imho. > >> >> ----- >> Karafman >> Slayer of the JEE >> Pounder of the Perl Programmer >> >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/Suggested-3-x-x-functionality-tp2597220p2597556.html >> Sent from the Karaf - Dev mailing list archive at Nabble.com. >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
