[xwiki-devs] [Proposal] Structure for extensions.xwiki.org
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) - 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) 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
Note that Ludovic has also published a proposal for extensions.xwiki.org here: http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiExtensionRepositoryRedesign It's quite similar but Ludovic's proposal is in between the proposal below and the extension manager proposal. From the proposal below it adds the ability to register one's wiki and adds more fields. I believe this can be added later on. Other fields can also be added later on; right now I'd like to keep it very simple on purpose (the more fields there are the more complex it is to add new entries). Thanks -Vincent On Apr 2, 2010, at 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) - 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)
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
Note that Ludovic has also published a proposal for extensions.xwiki.org here: http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiExtensionRepositoryRedesign It's quite similar but Ludovic's proposal is in between the proposal below and the extension manager proposal. From the proposal below it adds the ability to register one's wiki and adds more fields. I believe this can be added later on. Other fields can also be added later on; right now I'd like to keep it very simple on purpose (the more fields there are the more complex it is to add new entries). Thanks -Vincent On Apr 2, 2010, at 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) - 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)
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
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.
- 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?
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?
-- Sergiu Dumitriu http://purl.org/net/sergiu/
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
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 <[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
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
participants (3)
-
Ecaterina Valica -
Sergiu Dumitriu -
Vincent Massol