Vincent Massol wrote: > Hi devs, > > Right now we have: > > platform/ > |_ core/ > |_ xwiki-core/ > |_ (others)/ > |_ plugins/ > |_ ... > > The problem I see is twofold: > 1) We can have platform components that are not core components (for > example I'd like to commit the office component done by Wang Ning). > 2) I'd like that we decide to deprecate the plugins/ system going > forward and that all new code only write components. > > For 1) I'd like to propose: > > platform/ > |_ components/ (contains (others)/ from above) > |_ core/ (is the core/xwiki-core from above, to be removed once > fully split into components) > |_ plugins/ (to be removed once fully split into components) > |_ ...
+1. This means that we can't normally have components that depend on the core, since when building the whole trunks, the component will be built before the core, which is a pre-dependency. But this is a good restriction, anyway. > For 2) I'd like to propose: > > * Create an interface for Velocity APIs. Something like VelocityBridge > (or VelocityAccess or VelocityApi or...). It would be empty. > * Each component that want to be accessed from velocity will need to > implement a component implementing VelocityBridge. It'll have a role- > hint being the name under which it'll be access from Velocity. > * Create a VelocityService class (component) which has a single > get(String name) method and which uses the ComponentManager to look up > components which implement VelocityBridge using the name as the role > hint. > * Put that VelocityService in the Velocity context under the name > "services". This looks good. However, what will happen with the VelocityContextInitializer component? Is it to be used only for special purposes, like setting the $doc variables, the $services and other essential elements? > In practice this means that users will be able to access all our > components through the VelocityBridge implementations with a syntax > like: > > $services.office.convert(...) > $services.translation.translate(...) > ... > > Note1: We would need to be careful that it would be forbidden for any > java code to use a VelocityBridge. This is to ensure all code logic is > put into components and not into the bridges. We should use the maven > enforcer plugin to enforce this rule. > Note2: This means we'll have 2 APIs to maintain: the velocity one (the > bridges) + the "Java"' one (the main components). But I don't see any > other way... > I still prefer the automatic velocity API exposure from the actual java class, using annotations and uberspectors. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
