[xwiki-devs] [Proposal] Create a xlet repository for contributed apps/macros/plugins/etc.
Hi all, The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team. The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org). The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense). Here is my +1 for the above I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.) And my +1 for this second proposal Please, let me know what you think Jerome.
On Mon, Oct 5, 2009 at 18:00, Jerome Velociter <[email protected]> wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 for the XWik forge :) -- Thomas Mortagne
For the repository organization, I propose the following : xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...] Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org WDYT ? Jerome. Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Oct 6, 2009, at 2:45 PM, Jerome Velociter wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ?
+1 Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)). It could also be mentioned that at some point an Xlet project could be elected to become a platform project if the interest is generic, if it's voted and if the quality is good enough. Thanks -Vincent
Jerome.
Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome.
On Tue, Oct 6, 2009 at 2:55 PM, Vincent Massol <[email protected]> wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
+1 with the proposal but I'd prefer to name the project "contrib" since it's quite common and speaks for itself (particuraly considering the comment from Vincent above). WDYT ? See http://www.google.com/search?hl=en&q=%22Index+of+%2Fcontrib%22 Thanks, JV.
Jean-Vincent Drean wrote:
On Tue, Oct 6, 2009 at 2:55 PM, Vincent Massol <[email protected]> wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
+1 with the proposal but I'd prefer to name the project "contrib" since it's quite common and speaks for itself (particuraly considering the comment from Vincent above). WDYT ?
Yeah "contrib" has the advantage of being self-explanatory... I don't have strong feelings on this. "contrib" makes our job easier since it's less to explain, so Id be +0 for it over "xlet". Jerome.
See http://www.google.com/search?hl=en&q=%22Index+of+%2Fcontrib%22
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Tue, Oct 6, 2009 at 3:13 PM, Jerome Velociter <[email protected]> wrote:
Jean-Vincent Drean wrote:
On Tue, Oct 6, 2009 at 2:55 PM, Vincent Massol <[email protected]> wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
+1 with the proposal but I'd prefer to name the project "contrib" since it's quite common and speaks for itself (particuraly considering the comment from Vincent above). WDYT ?
Yeah "contrib" has the advantage of being self-explanatory...
I don't have strong feelings on this. "contrib" makes our job easier since it's less to explain, so Id be +0 for it over "xlet".
"contrib" sounds good to me too. Guillaume
Jerome.
See http://www.google.com/search?hl=en&q=%22Index+of+%2Fcontrib%22
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On Oct 6, 2009, at 3:13 PM, Jerome Velociter wrote:
Jean-Vincent Drean wrote:
On Tue, Oct 6, 2009 at 2:55 PM, Vincent Massol <[email protected]> wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
+1 with the proposal but I'd prefer to name the project "contrib" since it's quite common and speaks for itself (particuraly considering the comment from Vincent above). WDYT ?
Yeah "contrib" has the advantage of being self-explanatory...
I don't have strong feelings on this. "contrib" makes our job easier since it's less to explain, so Id be +0 for it over "xlet".
I agree xlet is not very self speaking and so far we've chosen meaningful names for our top level projects. +1 for "contrib" (or even with "contribution" which is the more correct name). Thanks -Vincent
Jerome.
See http://www.google.com/search?hl=en&q=%22Index+of+%2Fcontrib%22
Thanks, JV.
On Tue, Oct 6, 2009 at 15:07, Jean-Vincent Drean <[email protected]> wrote:
On Tue, Oct 6, 2009 at 2:55 PM, Vincent Massol <[email protected]> wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
+1 with the proposal but I'd prefer to name the project "contrib" since it's quite common and speaks for itself (particuraly considering the comment from Vincent above). WDYT ? See http://www.google.com/search?hl=en&q=%22Index+of+%2Fcontrib%22
+1 for contrib
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Vincent Massol wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
It could also be mentioned that at some point an Xlet project could be elected to become a platform project if the interest is generic, if it's voted and if the quality is good enough.
I agree. I think the best place for that would be a page on code.xwiki.org. I don't think we need a new wiki for the forge (except technically - for SVN), I would be to aggregate all info that concern contrib in code.xwiki.org since they are closely related. BTW I forgot to mention in the original email, I think we should propose a generic maven groupId for individuals or projects that don't want to come up with their own. Something like "org.xwiki.contrib". wdyt ? Jerome.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Oct 6, 2009 at 20:37, Jerome Velociter <[email protected]> wrote:
Vincent Massol wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
It could also be mentioned that at some point an Xlet project could be elected to become a platform project if the interest is generic, if it's voted and if the quality is good enough.
I agree. I think the best place for that would be a page on code.xwiki.org.
I don't think we need a new wiki for the forge (except technically - for SVN), I would be to aggregate all info that concern contrib in code.xwiki.org since they are closely related.
BTW I forgot to mention in the original email, I think we should propose a generic maven groupId for individuals or projects that don't want to come up with their own. Something like "org.xwiki.contrib".
all projects are supposed to have at least a name and generally can use org.xwiki.myproject I think
wdyt ?
Jerome.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Oct 7, 2009, at 9:47 AM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 20:37, Jerome Velociter <[email protected]> wrote:
Vincent Massol wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
It could also be mentioned that at some point an Xlet project could be elected to become a platform project if the interest is generic, if it's voted and if the quality is good enough.
I agree. I think the best place for that would be a page on code.xwiki.org.
I don't think we need a new wiki for the forge (except technically - for SVN), I would be to aggregate all info that concern contrib in code.xwiki.org since they are closely related.
BTW I forgot to mention in the original email, I think we should propose a generic maven groupId for individuals or projects that don't want to come up with their own. Something like "org.xwiki.contrib".
all projects are supposed to have at least a name and generally can use org.xwiki.myproject I think
The current rule is org.xwiki.<top level project> so if contrib is a top level project it seems logical to have org.xwiki.contrib. -Vincent
wdyt ?
Jerome.
Thanks -Vincent
On Wed, Oct 7, 2009 at 10:02, Vincent Massol <[email protected]> wrote:
On Oct 7, 2009, at 9:47 AM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 20:37, Jerome Velociter <[email protected]> wrote:
Vincent Massol wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
It could also be mentioned that at some point an Xlet project could be elected to become a platform project if the interest is generic, if it's voted and if the quality is good enough.
I agree. I think the best place for that would be a page on code.xwiki.org.
I don't think we need a new wiki for the forge (except technically - for SVN), I would be to aggregate all info that concern contrib in code.xwiki.org since they are closely related.
BTW I forgot to mention in the original email, I think we should propose a generic maven groupId for individuals or projects that don't want to come up with their own. Something like "org.xwiki.contrib".
all projects are supposed to have at least a name and generally can use org.xwiki.myproject I think
The current rule is org.xwiki.<top level project> so if contrib is a top level project it seems logical to have org.xwiki.contrib.
contrib is a repository of top level projects not a project itself IMO
-Vincent
wdyt ?
Jerome.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thomas Mortagne wrote:
On Wed, Oct 7, 2009 at 10:02, Vincent Massol <[email protected]> wrote:
On Oct 7, 2009, at 9:47 AM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 20:37, Jerome Velociter <[email protected]> wrote:
Vincent Massol wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
It could also be mentioned that at some point an Xlet project could be elected to become a platform project if the interest is generic, if it's voted and if the quality is good enough. I agree. I think the best place for that would be a page on code.xwiki.org.
I don't think we need a new wiki for the forge (except technically - for SVN), I would be to aggregate all info that concern contrib in code.xwiki.org since they are closely related.
BTW I forgot to mention in the original email, I think we should propose a generic maven groupId for individuals or projects that don't want to come up with their own. Something like "org.xwiki.contrib". all projects are supposed to have at least a name and generally can use org.xwiki.myproject I think The current rule is org.xwiki.<top level project> so if contrib is a top level project it seems logical to have org.xwiki.contrib.
contrib is a repository of top level projects not a project itself IMO
The problem with "org.xwiki.myproject" is that we lose the "not developed by the XWiki team" aspect that contrib brings. Jerome.
-Vincent
wdyt ?
Jerome.
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Oct 7, 2009, at 10:08 AM, Thomas Mortagne wrote:
On Wed, Oct 7, 2009 at 10:02, Vincent Massol <[email protected]> wrote:
On Oct 7, 2009, at 9:47 AM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 20:37, Jerome Velociter <[email protected]> wrote:
Vincent Massol wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
It could also be mentioned that at some point an Xlet project could be elected to become a platform project if the interest is generic, if it's voted and if the quality is good enough.
I agree. I think the best place for that would be a page on code.xwiki.org.
I don't think we need a new wiki for the forge (except technically - for SVN), I would be to aggregate all info that concern contrib in code.xwiki.org since they are closely related.
BTW I forgot to mention in the original email, I think we should propose a generic maven groupId for individuals or projects that don't want to come up with their own. Something like "org.xwiki.contrib".
all projects are supposed to have at least a name and generally can use org.xwiki.myproject I think
The current rule is org.xwiki.<top level project> so if contrib is a top level project it seems logical to have org.xwiki.contrib.
contrib is a repository of top level projects not a project itself IMO
I really don't like the idea of a repository of top level projects for contrib projects. I think I'd be -1 for having that. Same as we don't have a repo of top level sandbox project and a repo of top level platform projects. It would also break our top level project rule which is that projects at http://svn.xwiki.org/svnroot/xwiki/ are top level projects and have associated jira/wiki/etc. However as I mentioned I'm for being able to graduate from the contrib project to the platform project or even to a top level project if we want it, but on a case by case basis. Thanks -Vincent
On Thu, Oct 8, 2009 at 13:43, Vincent Massol <[email protected]> wrote:
On Oct 7, 2009, at 10:08 AM, Thomas Mortagne wrote:
On Wed, Oct 7, 2009 at 10:02, Vincent Massol <[email protected]> wrote:
On Oct 7, 2009, at 9:47 AM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 20:37, Jerome Velociter <[email protected]> wrote:
Vincent Massol wrote:
Note: It's important to write somewhere clearly that Xlet projects are not done by the xwiki dev team and not supported by the xwiki dev team (and thus that the quality depends on the contributor(s)).
It could also be mentioned that at some point an Xlet project could be elected to become a platform project if the interest is generic, if it's voted and if the quality is good enough.
I agree. I think the best place for that would be a page on code.xwiki.org.
I don't think we need a new wiki for the forge (except technically - for SVN), I would be to aggregate all info that concern contrib in code.xwiki.org since they are closely related.
BTW I forgot to mention in the original email, I think we should propose a generic maven groupId for individuals or projects that don't want to come up with their own. Something like "org.xwiki.contrib".
all projects are supposed to have at least a name and generally can use org.xwiki.myproject I think
The current rule is org.xwiki.<top level project> so if contrib is a top level project it seems logical to have org.xwiki.contrib.
contrib is a repository of top level projects not a project itself IMO
I really don't like the idea of a repository of top level projects for contrib projects. I think I'd be -1 for having that. Same as we don't have a repo of top level sandbox project and a repo of top level
This is exactly what is sandbox, do you see any applications/plugins/etc. folders ?
platform projects.
As I said the way it's organized between plugins and applications currently is wrong IMO. Also note that with your arguments there is no reason to have enterprise and manager top projects, all their sub projects should be extracted and organized by type instead of project.
It would also break our top level project rule which is that projects at http://svn.xwiki.org/svnroot/xwiki/ are top level projects and have associated jira/wiki/etc.
However as I mentioned I'm for being able to graduate from the contrib project to the platform project or even to a top level project if we want it, but on a case by case basis.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thomas Mortagne wrote:
On Thu, Oct 8, 2009 at 13:43, Vincent Massol <[email protected]> wrote:
On Oct 7, 2009, at 10:08 AM, Thomas Mortagne wrote:
On Wed, Oct 7, 2009 at 10:02, Vincent Massol <[email protected]> wrote:
On Oct 7, 2009, at 9:47 AM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 20:37, Jerome Velociter <[email protected]> wrote:
Vincent Massol wrote: > Note: It's important to write somewhere clearly that Xlet projects > are > not done by the xwiki dev team and not supported by the xwiki dev > team > (and thus that the quality depends on the contributor(s)). > > It could also be mentioned that at some point an Xlet project > could be > elected to become a platform project if the interest is generic, > if > it's voted and if the quality is good enough. I agree. I think the best place for that would be a page on code.xwiki.org.
I don't think we need a new wiki for the forge (except technically - for SVN), I would be to aggregate all info that concern contrib in code.xwiki.org since they are closely related.
BTW I forgot to mention in the original email, I think we should propose a generic maven groupId for individuals or projects that don't want to come up with their own. Something like "org.xwiki.contrib". all projects are supposed to have at least a name and generally can use org.xwiki.myproject I think The current rule is org.xwiki.<top level project> so if contrib is a top level project it seems logical to have org.xwiki.contrib. contrib is a repository of top level projects not a project itself IMO I really don't like the idea of a repository of top level projects for contrib projects. I think I'd be -1 for having that. Same as we don't have a repo of top level sandbox project and a repo of top level
This is exactly what is sandbox, do you see any applications/plugins/etc. folders ?
Actually yes, there is a plugin folder ;) But ok, it's a mix currently, plugins exists either under the root directory or under plugins/ I think the two debates groupId and SVN folder or not organzation are separate. We already have org.xwiki.platform.tools as groupId distinct from org.xwiki.platform (while there's none for applications, plugins, etc.) so the rule "groupId match SVN top level projects" is already invalidated - and I don't think we need such a strong rule anyway. I would be -1 too for org.xwiki.<projectname> groupIds for contrib projects (no regarding the fact we call them top level projects or not) for the simple reason that from an external PoV they appear as XWiki projects (read developed by the XWiki development team) which they are not. Jerome.
platform projects.
As I said the way it's organized between plugins and applications currently is wrong IMO.
Also note that with your arguments there is no reason to have enterprise and manager top projects, all their sub projects should be extracted and organized by type instead of project.
It would also break our top level project rule which is that projects at http://svn.xwiki.org/svnroot/xwiki/ are top level projects and have associated jira/wiki/etc.
However as I mentioned I'm for being able to graduate from the contrib project to the platform project or even to a top level project if we want it, but on a case by case basis.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter <[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ?
I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository.
Jerome.
Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter <[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ?
I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository.
Don't you think it's good to have that distinction by type of project ? Do you think we can manage this by project names ? (for example "plugin-myplugin", "application-myapplication") It would mean making sure contributors name their projects properly (it's easier to have them create their projects in the proper directory properly IMO). Jerome.
Jerome.
Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Oct 6, 2009 at 15:22, Jerome Velociter <[email protected]> wrote:
Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter <[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ?
I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository.
Don't you think it's good to have that distinction by type of project ?
Do you think we can manage this by project names ? (for example "plugin-myplugin", "application-myapplication") It would mean making sure contributors name their projects properly (it's easier to have them create their projects in the proper directory properly IMO).
Don't mix projects and maven artifacts, as i said most of our applications have a corresponding plugin/component with the same version you would like to release all in once. For me it should be based on what you want to build, we will never want to build all the xlet/applications/trunk/ but build/release/branch/etc.. xlet/myproject/trunk/ all in once will be needed. If we separate all, it will just make contributor life a pain for nothing, list project is already http://code.xwiki.org. It also mean we can handling committers rights by project, if we see this as a start of a XWiki forge we should definitely organize by project and not by maven artifacts types. At worst why not have theses artifact type project base folder but we also need a "project" folder or something like that where you can put a more important contribution which have more than just one artifact.
Jerome.
Jerome.
Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 15:22, Jerome Velociter <[email protected]> wrote:
Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter <[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ? I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository. Don't you think it's good to have that distinction by type of project ?
Do you think we can manage this by project names ? (for example "plugin-myplugin", "application-myapplication") It would mean making sure contributors name their projects properly (it's easier to have them create their projects in the proper directory properly IMO).
Don't mix projects and maven artifacts, as i said most of our applications have a corresponding plugin/component with the same version you would like to release all in once.
For me it should be based on what you want to build, we will never want to build all the xlet/applications/trunk/ but build/release/branch/etc.. xlet/myproject/trunk/ all in once will be needed. If we separate all, it will just make contributor life a pain for nothing, list project is already http://code.xwiki.org. It also mean we can handling committers rights by project, if we see this as a start of a XWiki forge we should definitely organize by project and not by maven artifacts types.
At worst why not have theses artifact type project base folder but we also need a "project" folder or something like that where you can put a more important contribution which have more than just one artifact.
OK, you fear that projects composed of several modules (like applications + plugin + macro) will be painful to handle from maven PoV if they are scattered over different folders. My only concern is that we might get project names that are not very descriptive (one would have to go and see its sources or pom.xml to know what it does). But we (XWiki Dev Team) can always interfere here as it concerns the repository organization, not projects themselves. Jerome.
On Tue, Oct 6, 2009 at 15:50, Jerome Velociter <[email protected]> wrote:
Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 15:22, Jerome Velociter <[email protected]> wrote:
Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter <[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ? I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository. Don't you think it's good to have that distinction by type of project ?
Do you think we can manage this by project names ? (for example "plugin-myplugin", "application-myapplication") It would mean making sure contributors name their projects properly (it's easier to have them create their projects in the proper directory properly IMO).
Don't mix projects and maven artifacts, as i said most of our applications have a corresponding plugin/component with the same version you would like to release all in once.
For me it should be based on what you want to build, we will never want to build all the xlet/applications/trunk/ but build/release/branch/etc.. xlet/myproject/trunk/ all in once will be needed. If we separate all, it will just make contributor life a pain for nothing, list project is already http://code.xwiki.org. It also mean we can handling committers rights by project, if we see this as a start of a XWiki forge we should definitely organize by project and not by maven artifacts types.
At worst why not have theses artifact type project base folder but we also need a "project" folder or something like that where you can put a more important contribution which have more than just one artifact.
OK, you fear that projects composed of several modules (like applications + plugin + macro) will be painful to handle from maven PoV if they are scattered over different folders.
My only concern is that we might get project names that are not very descriptive (one would have to go and see its sources or pom.xml to know what it does). But we (XWiki Dev Team) can always interfere here as it concerns the repository organization, not projects themselves.
You can have exactly the same issue with type based organization, if you know xlet/extensions/trunk/toto42 is a extension you have no idea what it really is. And as you said we are creating the project on svn so we can decide that a name does not fit with the provided description when someone ask for a new project in XWiki contrib repository. Also i really think we should think of security, even if we don't do it from the starts, if we organize by project it will be a lot easier to add rights management support the same we do this with project in svn.xwiki.org based on some ProjectClass objects rights in forge.xwiki.org for example instead of based on a group in some wiki. Would be a good start for a real XWiki forge and we already have everything we need to do it.
Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 15:50, Jerome Velociter <[email protected]> wrote:
Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 15:22, Jerome Velociter <[email protected]> wrote:
Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter <[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ? I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository. Don't you think it's good to have that distinction by type of project ?
Do you think we can manage this by project names ? (for example "plugin-myplugin", "application-myapplication") It would mean making sure contributors name their projects properly (it's easier to have them create their projects in the proper directory properly IMO). Don't mix projects and maven artifacts, as i said most of our applications have a corresponding plugin/component with the same version you would like to release all in once.
For me it should be based on what you want to build, we will never want to build all the xlet/applications/trunk/ but build/release/branch/etc.. xlet/myproject/trunk/ all in once will be needed. If we separate all, it will just make contributor life a pain for nothing, list project is already http://code.xwiki.org. It also mean we can handling committers rights by project, if we see this as a start of a XWiki forge we should definitely organize by project and not by maven artifacts types.
At worst why not have theses artifact type project base folder but we also need a "project" folder or something like that where you can put a more important contribution which have more than just one artifact.
OK, you fear that projects composed of several modules (like applications + plugin + macro) will be painful to handle from maven PoV if they are scattered over different folders.
My only concern is that we might get project names that are not very descriptive (one would have to go and see its sources or pom.xml to know what it does). But we (XWiki Dev Team) can always interfere here as it concerns the repository organization, not projects themselves.
You can have exactly the same issue with type based organization, if you know xlet/extensions/trunk/toto42 is a extension you have no idea what it really is.
but you know it's an extension (at least in theory) :)
And as you said we are creating the project on svn so we can decide that a name does not fit with the provided description when someone ask for a new project in XWiki contrib repository.
Also i really think we should think of security, even if we don't do it from the starts, if we organize by project it will be a lot easier to add rights management support the same we do this with project in svn.xwiki.org based on some ProjectClass objects rights in forge.xwiki.org for example instead of based on a group in some wiki. Would be a good start for a real XWiki forge and we already have everything we need to do it.
Anyway, +1 from me for this organization, you've convinced me. Jerome.
Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 10/06/2009 04:08 PM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter<[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ?
I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository.
+1, I think that this kind of organization also matches the normal discovery / exploration path. It happens often enough that an extra functionality on top of xwiki requires application, plugin/module/component and why not a bit of skin. It would be easier, for who would want to find out more about such an application, to go to a single place (contribution/washingdishesapp) and discover all sources in one place, without having to know from the beginning that it's a plugin and then some pages (most of the times when you're interested in an application, this is not the first thing you find out), hopefully it would be able to find that out by looking at the sources and digging further. baseline is that it would make it easier to learn for contributors and more natural, even if for us, the experts, another organization might seem better. For the record, I consider this annoying on code.xwiki.org, the fact that if you want to add extra functionality on top of xwiki, you have to go to several different categories of code to finally find how to add it -- it should be all in a single place, with instructions about how to make it happen. Thanks, Anca
Jerome.
Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Oct 8, 2009, at 2:08 PM, Anca Paula Luca wrote:
On 10/06/2009 04:08 PM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter<[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ?
I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository.
+1,
I think that this kind of organization also matches the normal discovery / exploration path. It happens often enough that an extra functionality on top of xwiki requires application, plugin/module/component and why not a bit of skin. It would be easier, for who would want to find out more about such an application, to go to a single place (contribution/washingdishesapp) and discover all sources in one place, without having to know from the beginning that it's a plugin and then some pages (most of the times when you're interested in an application, this is not the first thing you find out), hopefully it would be able to find that out by looking at the sources and digging further.
baseline is that it would make it easier to learn for contributors and more natural, even if for us, the experts, another organization might seem better.
For the record, I consider this annoying on code.xwiki.org, the fact that if you want to add extra functionality on top of xwiki, you have to go to several different categories of code to finally find how to add it -- it should be all in a single place, with instructions about how to make it happen.
Anca, as soon as you start to have lots of items I think it's a mess if you have no hierarchy. You can't list them anymore. We have a search, using the search you get a flat hierarchy. Actually I agree with you to transform code.xwiki.org home page by having a single live table with column filtering on the type column (where type = snippet, macro, etc). + maybe a what's new with aggregated types listed. Thanks -Vincent
Thanks, Anca
Jerome.
Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome.
On 10/08/2009 03:15 PM, Vincent Massol wrote:
On Oct 8, 2009, at 2:08 PM, Anca Paula Luca wrote:
On 10/06/2009 04:08 PM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter<[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ?
I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository.
+1,
I think that this kind of organization also matches the normal discovery / exploration path. It happens often enough that an extra functionality on top of xwiki requires application, plugin/module/component and why not a bit of skin. It would be easier, for who would want to find out more about such an application, to go to a single place (contribution/washingdishesapp) and discover all sources in one place, without having to know from the beginning that it's a plugin and then some pages (most of the times when you're interested in an application, this is not the first thing you find out), hopefully it would be able to find that out by looking at the sources and digging further.
baseline is that it would make it easier to learn for contributors and more natural, even if for us, the experts, another organization might seem better.
For the record, I consider this annoying on code.xwiki.org, the fact that if you want to add extra functionality on top of xwiki, you have to go to several different categories of code to finally find how to add it -- it should be all in a single place, with instructions about how to make it happen.
Anca, as soon as you start to have lots of items I think it's a mess if you have no hierarchy. You can't list them anymore.
true, but we could categorize from a functionality / user pov, not a technical implementation pov.
We have a search, using the search you get a flat hierarchy.
probably, but the fact that, when searching for 'washing dishes application", one would get 3 results (one for the app, one for the underlying plugin and one for the skin), is puzzling ("wha' there's more than 1 app for washing dishes? which one I need to install? I want an application, I don't want the plugin.damn it doesn't work. and why doesn't it look like the screenshot? ah, I need a skin"). search would only point you in various places of the non-flat hierarchy and you'd still need to understand the whole hierarchy to figure out why, and how these dots connect together. when I first tried to use the code.xwiki.org to install an application, I hit these problems, and I did have some experience with xwiki at that point. Thanks, Anca
Actually I agree with you to transform code.xwiki.org home page by having a single live table with column filtering on the type column (where type = snippet, macro, etc).
+ maybe a what's new with aggregated types listed.
Thanks -Vincent
Thanks, Anca
Jerome.
Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Anca, On Thu, Oct 8, 2009 at 2:48 PM, Anca Luca <[email protected]> wrote:
On 10/08/2009 03:15 PM, Vincent Massol wrote:
On Oct 8, 2009, at 2:08 PM, Anca Paula Luca wrote:
On 10/06/2009 04:08 PM, Thomas Mortagne wrote:
On Tue, Oct 6, 2009 at 14:45, Jerome Velociter<[email protected]> wrote:
For the repository organization, I propose the following :
xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/) |__applications/ |__trunk/ |__xapp1/ |__xapp2/ [...] |__xappN/ |__branches/ [...] |__tags/ [...] |__extensions/ [...] |__macros/ [...] |__modules/ [...] |__plugins/ [...] |__skins/ [...]
Each of the first level sub-directory (applications, extensions, macros, etc.) having the same meaning of is currently defined on code.xwiki.org
WDYT ?
I'm not sure it's the right way, i think i would prefer to have the projects directly under xlet/ and have each project decide its own organization. It's a real pain currently to release plugin and applications which for lot of them should be released together, we should try to go the right way this time for a new repository.
+1,
I think that this kind of organization also matches the normal discovery / exploration path. It happens often enough that an extra functionality on top of xwiki requires application, plugin/module/component and why not a bit of skin. It would be easier, for who would want to find out more about such an application, to go to a single place (contribution/washingdishesapp) and discover all sources in one place, without having to know from the beginning that it's a plugin and then some pages (most of the times when you're interested in an application, this is not the first thing you find out), hopefully it would be able to find that out by looking at the sources and digging further.
baseline is that it would make it easier to learn for contributors and more natural, even if for us, the experts, another organization might seem better.
For the record, I consider this annoying on code.xwiki.org, the fact that if you want to add extra functionality on top of xwiki, you have to go to several different categories of code to finally find how to add it -- it should be all in a single place, with instructions about how to make it happen.
Anca, as soon as you start to have lots of items I think it's a mess if you have no hierarchy. You can't list them anymore.
true, but we could categorize from a functionality / user pov, not a technical implementation pov.
We have a search, using the search you get a flat hierarchy.
probably, but the fact that, when searching for 'washing dishes application", one would get 3 results (one for the app, one for the underlying plugin and one for the skin), is puzzling ("wha' there's more than 1 app for washing dishes? which one I need to install? I want an application, I don't want the plugin.damn it doesn't work. and why doesn't it look like the screenshot? ah, I need a skin").
search would only point you in various places of the non-flat hierarchy and you'd still need to understand the whole hierarchy to figure out why, and how these dots connect together.
when I first tried to use the code.xwiki.org to install an application, I hit these problems, and I did have some experience with xwiki at that point.
I think we'd all prefer a way to package our applications so that they include all the resources needed to make them work (Skin + Translations + Application + JAR) instead of the current breakdown in various subparts. However we still have a work to achieve this (most notably on the Application Manager). I'm not sure whether it would be better to change the current organization of code.xwiki.org (even though I agree it's confusing) until we get to the point where our application deployment modem / storage format matches the "1 unique search result per application" vision. Additionally, this doesn't solve the issue of dependancy (one plugin might be needed for 2 distinct applications -> should it be packaged in both by default?). The optimal solution would be an application manager where the user selects an application and al required packages are automatically downloaded (àla apt-get) but we're not there yet. In the meanwhile I'm not sure what's the best thing to do (statu quo, trying to improve code.xwiki.org with information messages...) Guillaume
Thanks, Anca
Actually I agree with you to transform code.xwiki.org home page by having a single live table with column filtering on the type column (where type = snippet, macro, etc).
+ maybe a what's new with aggregated types listed.
Thanks -Vincent
Thanks, Anca
Jerome.
Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi, On Mon, Oct 5, 2009 at 6:00 PM, Jerome Velociter <[email protected]> wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
+1 too. Guillaume I would also like to propose that we create a new category of JIRA
projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi Jerome, On Oct 5, 2009, at 6:00 PM, Jerome Velociter wrote:
Hi all,
The subject has been discussed already, see for example http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in the sense of everything applications, macros, components, plugins, skin extensions, etc.) that are not part of any products (or the platform) and that are not necessarily contributed by the XWiki development team.
What needs to be mentioned is that it'll be open to anyone who ask for it.
The difference with the sandbox is that sandbox is a place for modules being incubated, and that are not in a finished state. Thus, I think one of the rule for introducing new modules in the xlet repository would be that a functional version of the module should be released and available for download (for example on code.xwiki.org).
I'm ok with this but it also means that we should allow anyone who ask for it access to the sandbox so that there's a path from sandbox to xlet. It wouldn't be mandatory but people who want to start coding int he sandbox could access it.
The name "xlet" is the name we've use historically to talk about this repository, this is open for discussion. (personally I like the name - we have to agree this is how we want to name a XWiki "pluggable module" in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA projects : "XWiki Contributed Xlets" (or equivalent name) for such projects that desire to track issues for their released module, and have the tracker hosted by XWiki.org. I believe this will make easier to have real release cycles for such modules (for example, we can link to the JIRA project from the code.xwiki.org "module" page so that users can report issues instead of using the comments, we can use JIRAs changelog for release notes on the download page, etc.)
+1 Thanks -Vincent
And my +1 for this second proposal
Please, let me know what you think Jerome.
participants (7)
-
Anca Luca -
Anca Paula Luca
-
Guillaume Lerouge -
Jean-Vincent Drean -
Jerome Velociter -
Thomas Mortagne -
Vincent Massol