On Sep 1, 2008, at 9:23 AM, Anca Paula Luca wrote: > 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?
Plugins are in plugins/ dir and will stay there until they're transformed into components. Then there's no restriction about depending on core till it's split into small components. Thanks -Vincent >>> 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
