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 <[email protected]> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
