On 04/02/2010 12:22 PM, Vincent Massol wrote: Why a distinct download page? I find it hard to manage it like this.

Macro and Snippet are added along the ExtensionClass?

> 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?

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?

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