On 9/2/14, 4:08 PM, Christophe Bouhier wrote: > 1. Do you plan to make it 'native' OSGI bundles (not using the > maven-bundle-plugin, but editing of the MANIFEST.MF so the meta is > static).
No, we don't plan to move to manually editing the manifests. The bundle plugin does everything we need to right now. If you want to add more fields to the manifest, you can put them into the configuration in the POM. Is there something particular that you want to do that the plugin doesn't do? > > 2. How does Karaf deal with the SpringFramework wireing? (Do you use > the classloading mechanism of karaf to deal with bundle dependencies, > but how is the application context kicked in?). Right now, we don't have a "best practice" for how to deal with this. I would say that for simple Spring contexts, you can provide an OSGi Blueprint context (/OSGI-INF/blueprint/*.xml) that performs the same wiring. We're using this on new code and it works fine but does not support annotation scanning or autowiring. The alternative is that you can use Spring DM to load the XML contexts. To do this, you just have to add a <Spring-Context> value to the MANIFEST.MF and then load the Spring DM deployer in Karaf. However, Spring DM is deprecated and its replacement, Gemini Blueprint, is not supported in Karaf 2.3.X so we haven't had a chance to test it out at all yet. It's not clear how well-supported Gemini Blueprint will be in the future. > > 3. Do you consider an alternative to SpringFramework wireing? So > perhaps OSGI Declarative Services or ServiceTracker? (I don't see how > the springframework fits in the OSGI picture?). OSGi Blueprint is the best alternative we have now. It has been working great for us in new projects. It's basically the same XML format as Spring but with all of the OSGi integration that you need. Unit testing is challenging for us but other than that, it's been a smooth transition from exclusively using Spring. > I hope you don't mind the clone and name space change, but its really > to try out stuff (PoC) and I noticed your namespaces clashes here and > there. (You have multiple packages named. org.opennms.core.utils.) Yes, these are the namespace clashes that prevent some of our bundles from loading properly. The number of these clashes is shrinking every day! :) Please keep us up-to-date with your progress. If you are able to refactor the DAO classes with your own implementation, that would also be a nice improvement. Hopefully you'll be free to release the code under the GPL! :) I look forward to hearing about your progress on this opennms-devel list. -- Seth ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
