6 Apr
2010
6 Apr
'10
3:03 p.m.
On Apr 6, 2010, at 2:42 PM, Ecaterina Valica wrote:
The current naming for the extensions
http://code.xwiki.org/xwiki/bin/view/Extensions/
is kind of confusing with the one given to the general extensions.xwiki.org.
We should find another name for the external modules, or we put them in
Other section?
In the proposal all extensions are put as extensions and listed in one category:
extensions.
The rationale is that a user shouldn't have to know if what he looks for is a macro,
snippet, application, other type of extension. He's looking for something to solve a
need.
Thats said, I've mentioned a "type" below for advanced users who want to
list only extensions of a given type. What we currently call "extensions" will
go in the "others" category. Types are:
macro, snippet, application, plugin, skin, other. Composite extensions will also be listed
as "other" (as mentioned below).
Thanks
-Vincent
Thanks,
Caty
On Tue, Apr 6, 2010 at 10:48, Vincent Massol <vincent(a)massol.net> wrote:
>
> On Apr 3, 2010, at 3:46 PM, Sergiu Dumitriu wrote:
>
>> On 04/02/2010 12:22 PM, Vincent Massol wrote:
>>> Hi,
>>>
>>> I'm implementing the mail entitled "[Proposal] Rationalize our
projects
> and SVN structure" and I need to start creating extensions.xwiki.org (a
> **first** version of it).
>>>
>>> Here's my current thinking re its structure:
>>>
>>> * An ExtensionClass
>>> - Description
>>> - icon (optional)
>>> - Download page (optional)
>>
>> Why a distinct download page? I find it hard to manage it like this.
>
> Yes, I agree that we should store the DownloadClass objects in the same
> page.
>
>>> - created by
>>> - contributor
>>> - bundled with (none, top level projects except contrib, extensions)
>>> - content (with template having Tested With + Requirements sections)
>>> - type (macro, snippet, application, plugin, skin, other)
>>>
>>> * A MacroClass
>>> - macro type
>>>
>>> * A SnippetClass
>>> - languages (multi choice list: script languages)
>>
>> Macro and Snippet are added along the ExtensionClass?
>
> Yes since they contain additional data, not common with other extension
> types.
>
>>> Note: In the future we'll need to map these classes to the Extension
> Manager descriptor, with dependencies for example.
>>>
>>> * Have an ExtensionClassSheet that does basically the same thing as now
>>> * Have an ExtensionClassTemplate with predefined sections to guide the
> author: Usage, Installation& Requirements, Tested With (note: Installation&
> Requirements could also be put in the Download page, common to all
> versions)
>>> * Keep the Download classes too for now
>>> * On the home page, have a big livetable mapped to ExtensionClass for
> now.
>>>
>>> * Put all extensions in an Extensions space
>>> * Use a prefix of "Extension"
>>> * When an extension is made of different "types", then bundle it as
a
> zip with type "other". For example the Watch extension is made of a XAR +
2
> jars, it would be bundled as a zip and a type of "other".
>>>
>>> * Move Module References to platform.xwiki.org
>>>
>>> * Possibly write some scripts to help migrate current content on
> code.xwiki.org to extensions.xwiki.org
>>>
>>> WDYT?
>
> Thanks
> -Vincent