Felix Meschberger wrote: > Hmm, what this boils down to. So we currently have two options to decide > on: The Jar Service provider mechanism and the servlet init-param > listing classes. > > In the light of having a real Sling supporting OSGi extension model, I > would not make it too easy for microsling to be extensible and implement > a separate extension model (Jar Service provider) and hence stick with > the init-param method. > > On the other hand, if we create the microsling-core only containing > JavaScript and have a microsling-scripting-ext which contains a bunch of > other scripting engines. What would go in the microsling-webapp ? Do we > include microsling-scripting-ext or not ? I would say, we include and > have a web app with everything but concentrate on the microsling-core > project and just have microsling-scripting-ext as a by-product where we > can dump scripting engines over time. Yepp, that was my intention.
> > On the other hand we could create a separate project for each scripting > engine (probably outside of microsling inside a sling-scripting > container. These would be implemented such as to provide easy use in the > real sling. To be used in microsling, the microsling-webapp would have > to be manually modified. I'm not sure if we should create one project with all additional engines or one project per engine. But in any case, we can add all engines to the init parameter of the microsling-webapp. If one project contains all additional engines, we have just to change this parameter in web.xml; if there's one project per engine, we have to change the parameter and add the dep to the pom. That doesn't look like too much work. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
