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
