> If the customer bundles Import-Package: groovy.* then some bundle > somewhere is going to have to Export-Package: groovy.*, otherwise the > customer bundles will not resolve.
Of course. The Groovy .jar file is a bundle itself and exports it's own package. Thanks Neil. It sounds like this will work just fine. ----- Original Message ----- > Inline again... > > On Fri, Mar 4, 2011 at 7:24 AM, Hamlet DArcy <[email protected]> > wrote: > > My goal is to have groovy.* packages in the Import-Package list but > > not the Export-Package list. Then it will be a dependency that can > > vary between bundles. And it needs to vary between bundles. We > > want to write and test a customer extension today in 2011 with > > Groovy 1.7, deploy it, and then never need to upgrade the Groovy > > version, even though next year some customers will be on Groovy > > 1.8. I wrote a prototype for this in 2009 and it seemed to work. > > If the customer bundles Import-Package: groovy.* then some bundle > somewhere is going to have to Export-Package: groovy.*, otherwise the > customer bundles will not resolve. > > I suggest you deploy a set of Groovy bundles that simply wrap the > Groovy API and export it under the correct version. Of course you can > have multiple versions of the Groovy API bundle. > > > The general prototype executed Groovy scripts against 3 different > > versions of Groovy within the same Thread, and required 4 bundles: > > > > Interfaces 1.0 > > - Java only bundle to define a service interface and Java based > > transfer objects > > - Hardly any Package-Imports, only Package-Export was defined > > interfaces and transfer objects > > Provider 1.6 > > - Service that implements Interfaces 1.0, Import Groovy 1.6, > > Export only existing shared interfaces > > Provider 1.7 > > - Service that implements Interfaces 1.0, Import Groovy 1.7, > > Export only existing shared interfaces > > Evaluator 1.0 > > - Starts and runs application > > - Imports Interfaces 1.0 and both Provider 1.6 and Provider 1.7 > > This part will be a problem... a single bundle cannot import multiple > versions of the same interface. See my suggested alternative below. > > > - Dispatches requests to the correct Provider > > > > It is my belief, that Groovy can be a private dependency as long as > > all the transfer objects and interfaces are defined and shared in > > a separate bundle, and Groovy classes do not leak out into any > > shared API. > > Is it REALLY necessary for your Evaluator to know that the customer > bundles are implemented with Groovy? If not I suggest the following > alternative design: > > * "Interfaces" bundle exports the Provider interface > * "Evaluator" bundle imports the Provider interface and tracks > instances of the Provider interface. > * Customer bundles publish instances of Provider as services. How > they > implement the Provider interface is entirely up to them... they can > do > it in Groovy by importing any version they like... or they can choose > to implement in Java, Scala, JRuby, whatever. > > You can even implement your Evaluator in Groovy if you like! The > service interface provides an isolation barrier between the Evaluator > and the customer bundles, so they can have separate class-spaces > containing separate versions of Groovy. The only classes that need to > be shared are the Provider interface and any types exposed in that > interface. > > Regards, > Neil. > > > > > > > That's not really a question... just hoping someone can tell me if > > I'm being naive. > > > > -- > > Hamlet > > > > > > > > ----- Original Message ----- > >> Hi Hamlet, > >> > >> My responses inline below. > >> > >> On Fri, Mar 4, 2011 at 6:50 AM, Hamlet DArcy > >> <[email protected]> > >> wrote: > >> > Hi all, > >> > > >> > I am hoping for some architectural/design guidance. > >> > > >> > I have an existing application that loads & executes Groovy > >> > scripts > >> > from disk in order to provide custom logic to different > >> > customers. > >> > For instance, Customer X is mapped to a certain directory and > >> > the > >> > custom validation rules sit in "validation.groovy" in that > >> > customer's directory. We have almost 5000 scripts that get > >> > executed this way. I want to use OSGi to execute the scripts > >> > because then each customer can specify which version of Groovy > >> > to > >> > use (modularity) but the calls are still in process and fast. > >> > > >> > My idea is to define an OSGi service interface and have 3 > >> > implementations (Groovy 1.6, Groovy 1.7, and Groovy 1.8). The > >> > script controller will know what version to execute against and > >> > dispatch processing to the correct OSGi bundle that has that > >> > version of Groovy as a private dependency. > >> > > >> > My questions: > >> > 1) Do you see any obvious problems with this approach? > >> > >> I'm not sure if you will be able to do it using a service oriented > >> approach. The reason is that I believe that your customer's Groovy > >> scripts will have dependencies on the Groovy standard library. I > >> don't > >> know much about Groovy but I expect that it has some kind of > >> standard > >> library, equivalent to java.lang, java.util etc in the Java > >> language... am I correct? > >> > >> If that's the case then each customer's bundle has a *static* > >> dependency on a specific version of Groovy that is best expressed > >> through Import-Package. For example: > >> > >> Import-Package: groovy.lang;version="[1.6,2.0)" > >> > >> This allows your customer's bundle to express that it depends on > >> at > >> least Groovy 1.6, but it will also run on 1.7, 1.8, 1.256 etc. > >> > >> > 2) How easy & performant is it to embed an OSGi container into > >> > my > >> > existing application? > >> > >> Very easy if you use the OSGi R4.2 framework launching API. Just > >> the > >> following few lines of code will start an OSGi framework: > >> > >> FrameworkFactory factory = > >> ServiceLoader.load(FrameworkFactory.class); > >> Map<String,String> props = new HashMap<String,String>(); > >> // set some properties > >> Framework framework = factory.newFramework(props); > >> framework.start(); > >> > >> Now install and start a bundle: > >> > >> Bundle b = > >> > >> framework.getBundleContext().installBundle("file:/path/to/my/bundle.jar"); > >> b.start(); > >> > >> Finally wait for the OSGi framework to shutdown: > >> > >> framework.waitForStop(0); > >> > >> > 3) Do you have any recommendations on which container to use? > >> > >> Equinox, Felix and Knopflerfish are all fine containers and they > >> all > >> support the above API. If you stick to the standard API then you > >> can > >> remain independent of any specific container. I recommend you do > >> this... then after building your application you can evaluate > >> which > >> container offers the best non-functional environment for your > >> needs. > >> > >> > 4) Do you have an links or examples that are a good starting > >> > point > >> > on how to do this? > >> > > >> > Thanks in advance, > >> > > >> > -- > >> > Hamlet D'Arcy > >> > [email protected] > >> > > >> > _______________________________________________ > >> > OSGi Developer Mail List > >> > [email protected] > >> > https://mail.osgi.org/mailman/listinfo/osgi-dev > >> > > >> > >> _______________________________________________ > >> OSGi Developer Mail List > >> [email protected] > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > >> > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
