Hi Anca,
On Thu, Oct 8, 2009 at 2:48 PM, Anca Luca <ancapaula.luca(a)xwiki.com> 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<jerome(a)xwiki.com>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/