Richard S. Hall a écrit : > Eric Blanchard wrote: >> Hello community, >> >> I'm looking for some advises to organize the project >> layout/split in order to be able to provide the best >> environment for developing/deploying a set of N consumers >> and P providers OSGi services (I will use Declarative >> Services technique for that). >> >> Each Service is represented by a Java Interface. I plan to >> package each classes with associated documentation in a >> separate jar to make the java interfaces available for >> developers (service providers and services consumers). >> >> Service providers and service consumers projects will depend >> on the provided jar. They will build bundles that will have >> the package of the service interface in their Import-Package: >> directive. >> >> At deployment, what is the best way to make the Service >> interface available in the OSGi framework ? >> >> - Should I package each interface class in a separate bundle >> and install them in the framework before consumers and providers >> are resolved ? The risk is to end up with a great number >> of bundles (may be not very efficient to have one class loader >> per service interface). >> > > This would be okay. > >> - Should I put each interface in a fragment ? If yes, should I >> attach this fragment to the System bundle ? (may need to extend >> the Export-Package list each time I want to add a new services). >> > > I would not recommend this approach, since it is not really the intended > use case of fragments. >
OK >> - Should I let each service consumer bundle to embed a copy of >> the interface ? (I possibly loose coherency). >> > > Well, you wouldn't lose coherency, but usually consumers do not embed > the interface, rather the service providers embed the interface and then > they import AND export the service interface package so that they can > either use their own copy or share with another bundle that is already > providing the package. > >> - Any other solutions ? >> > > I, personally, would have each service provider embed the service > interface package and then import/export it. If your service interface > packages are small, then this should not add much overhead. OK, but I also plan to have these services "optional". Using Declarative Service will help me in the dynamic binding and I can refer to service interface as Dynamic-Import: in service consumer bundles to let them resolved, but I plan to use a Proxy pattern in consumers to hide the dynamic aspect of the service, so I need to have access to the service interface even if no service provider is loaded in the framework. > > -> richard Thanks a lot for your help. -- Eric > >> For the moment I prefer the first solution, but I'm afraid that >> the order and the number of bundles will be difficult to manage. >> >> Thanks in advance for your help. >> >> -- >> Eric >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
