Raul, Personally, I find this policy to be a bit too scientific and it is likely to confuse most of our users. From a consistency standpoint why not pick one path, Bundle or Fragment, and roll with it.
According to OSGI Wiki [1], a Fragment is something that belongs to a parent bundle and shares the same class-loader as the parent bundle. In our case, this is true for all the Ignite dependencies. Wouldn’t it be more appropriate to treat all Ignite dependencies as “Fragments”. [1] http://wiki.osgi.org/wiki/Fragment On Wed, Nov 11, 2015 at 3:41 AM, Raul Kripalani <ra...@apache.org> wrote: > Hey Dmitriy, > > On Wed, Nov 11, 2015 at 1:52 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > Can you please describe again the philosophy between choosing a fragment > or > > a bundle for Ignite dependencies. I couldn’t fully grasp it from your > > explanation. > > > > Yes, sorry, I was somewhat brief (it was late here ;-)). The policy I've > followed is to create bundles as a first preference. I've resorted to > fragments in the following circumstances: > * Split package situation, e.g. package > org.apache.ignite.internal.processors.query.h2.opt, exported by several > modules with different contents. > * Dynamic discovery, e.g. the one that takes place in > IgniteH2Indexing#createH2SpatialIndex. Since we cannot resolve this > situation using a package import (because there would be multiple bundles > exporting that package), therefore by using a fragment we are injecting > these classes into the class-space in the host bundle. > * Modules offering the components listed in IgniteComponentType, which are > discovered dynamically. > > Modules that are represented as fragments are: geospatial, indexing, jta, > spring, ssh. > > *Raúl Kripalani* > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and > Messaging Engineer > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk >
