This is a bit long winded but as you are new to OSGi before you make your next step ... As you have probably realised by now there are a few ways of achieving your goal, it can be difficult trying to distill the information on the Web and come up with the 'best' way to wire up services between bundles. Even in this one thread three different ways have been mentioned, Pax-CDI, Blueprint (of which there are 2 flavours) and Declarative Services, there are others not mentioned. Unfortunately you are unlikely to get a general consensus as to the best way forward and even that may depend on what you are ultimately trying to achieve. But some of the things that you may want to take into consideration before opting for a particular technology is whether it is widely used, backed by a specification e.g. OSGi Alliance, has there been any recent enhancements to the specification, are there any new specifications that may effect your decision, does the technology offer the life cycle dynamics that OSGi can provide. Take CDI for example, as mentioned above there is already an implementation, Pax-CDI, the OSGi Alliance has also a published https://github.com/osgi/design/blob/master/rfcs/rfc0193/rfc-0193-CDI-Integration.pdf, how will this effect the Pax-CDI project? Is there another implementation on its way? Take Aries Blueprint, it is widely used but from my understanding the Blueprint specification has not been touched for 5 years or so since it was first released in OSGi 4.2. Take Declarative Services as another example, this technology is widely used, has recent specification enhancements, is enthusiastically promoted by the founder of the enroute project (http://enroute.osgi.org/), promoted by the bndtools community, but at the moment takes a bit more work to integrate with other technologies such as CXF, Camel than say Aries Blueprint, although I think there is good work going on in these projects to make it easier. Another consideration is although it may be seemingly possible to do something in a certain way, can you have a high level of confidence that the library has extensive tests to support it. As an example, my company recently engaged Paremus to write the the tx-control project which underpins the transaction management of our system, there are over 3500 lines of test code in that project. I think you would agree that for something as fundamental as transactional management of persistence you really want a high level of confidence that it does work and wont be easily inadvertently broken in later releases (obviously unashamedly trying to convince you of the merits of tx-control :)
Hope this helps, Tim -- View this message in context: http://karaf.922171.n3.nabble.com/Multiple-bundles-dependencies-injection-pax-cdi-or-blueprint-tp4049756p4049776.html Sent from the Karaf - User mailing list archive at Nabble.com.
