Hi TL;DR We have to cleanup APIs and exports from Sightly Engine and JS UseProvider bundles.
I have been going through the Sightly Engine and JS UseProvider bundles. The JS UseProvider bundle currently exports everything at the bundle version. I would think this bundle should not be exporting anything at all. To leverage the default bundle plugin setup, I suggest we move everything into an impl package such that the top level will be org.apache.sling.scripting.sightly.js.impl. The case for the Sightly Engine is slightly more complicated. That bundle currently the .api package contains the exported API while the rest of the packages are implementations. As with the JS UseProvider I suggest to move all implementation packages to below org.apache.sling.scripting.sightly.impl. This allows us to leverage the default setup of the bundle plugin to not export anything containing impl in the package name. As for the API, I would like to propose to refactor a bit to create multiple smaller packages which are more coherent in their export: o.a.s.scripting.sightly: - ObjectModel - Record - ResourceResolution - SightlyEngineException extends SlingException - SightlyParsingException extends SightlyEngineException - SightlyRuntime - StackedWriter o.a.s.scripting.sightly.extension: - ExtensionInstance - RuntimeExtension - RuntimeExtensionComponent - RuntimeExtensionException extends SightlyEngineException o.a.s.scripting.sightly.render: - BaseRenderUnit - RenderContext - RenderUnit - SightlyRenderException extends SightlyEngineException - UnitLocator o.a.s.scripting.sightly.use: - ProviderOutcome - SightlyUseException extends SightlyEngineException - Use - UseProvider - UseProviderComponent Apart from splitting the base .api package, this are further discussions: * Exceptions are forming a hierarchy with SightlyEngineException being the root and itself extending from SlingException * I wonder, whether we should really drop the *Component abstract classes (RuntimeExtensionComponent and UseProviderComponent). I don’t think they provide real value at all but have an activate method, which they expect to be called and which they expect to be a DS component annotated with the Felix annotations. I think this is brittle. * UseProvider defines an ordering method and declares itself being Comparable. I think this is wrong. The UseProviders should be sorted using regular OSGi service ranking. * I wonder, whether we really have to have all this API exported at all: Some API I don’t see implemented at all (e.g. BaseRenderUnit — or is that the base class for the Java classes generated from the Sightly templates ?) * Last but not least (actually most important of all): There is close to no JavaDoc. Before cutting a release of this bundle, JavaDoc must be provided for the API. For example I am not sure, what the Record or the ObjectModel interfaces are really used for. Thanks Felix
