1 Sep
2008
1 Sep
'08
9:39 a.m.
On Sep 1, 2008, at 9:23 AM, Anca Paula Luca wrote:
Sergiu Dumitriu wrote:
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
Vincent Massol wrote:
But how is this compatible with the plugins transformation to
components? Don't
plugins (at least some) use/need the core? 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.