Sergiu Dumitriu wrote: > 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.
But how is this compatible with the plugins transformation to components? Don't plugins (at least some) use/need the core? > >> 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. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
