8 Nov
2014
8 Nov
'14
2:31 p.m.
On Thu, Nov 6, 2014 at 2:24 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Nov 6, 2014 at 1:13 PM, vincent(a)massol.net
<vincent(a)massol.net>
wrote:
features
visible in the app themselves whether it’s for end users,
developers or admins. For example the fact that in the Wiki Index, you can
have an “Edit Descriptor” button if you’re an admin of that wiki, or the
fact that in the AllDocs livetable page, you can delete a doc if you have
the permissions. Basically you see actions that you have the right to
perform.
Exactly. I wanted to point that out too, since I get the feeling that
Guillaume made it sound like we would be forced to move the wiki descriptor
in the local wiki if we want to make it editable from the subwiki's
administration too, which is not the case.
Also, note that for Workspaces (initial implementation) it was previously
possible to edit the subwiki`s descriptor (which was located on the main
wiki) from inside the subwiki`s Administration, which was a natural thing
to do IMO. I would like to have us be able to do that too with the 'wiki'
refactoring since:
A) the applications bar is not good for these things (plus it gets crowded
really fast and I think it's not a very good idea anyway, except just for a
user-configurable 'favorite' apps, but not for *all* apps since it does not
make sense). The only purpose of the app bar, IMO, should be for
user-favorite apps only, with admin selected/proposed defaults (like we do
for the User Directory customization).
B) configuring the wiki descriptor is not really something *that* optional
once you start deploying. It's not an application that you can or can not
have. For the n-th time, I would like to stress out the importance of the
wiki module and that it should not be considered as something optional, but
part of the wiki model itself, thus, no reason to place it into the
'Applications' section for the same reason why we don`t have Rights or
Users in the 'Applications' section; they are part of the model and core
features.
I hope we have not diverged too much from the topic of this thread, but I
do feel this discussion is related, in the end, to being able to set the
wiki's homepage from a sensible, reasonable and user discoverable location.
Thanks,
Eduard
On 6 Nov 2014 at 12:58:48, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
We had this discussion one year ago with Vincent.
He wanted to go in the
direction where everything is an application with a proper UI and not
necessary in the administration.
Some points on this to be clear:
1) Indeed for discoverability I think it's good to have application
2) Regarding configuration of apps, I agree that the best place is the
Administration with sections for each app. What I didn’t want to have is to
force the users to be admin to be able to access applications. For example
at the time the discussions were about the Scheduler app, the Statistics
app just to name 2. It was proposed that they be visible/findable only from
the Admin screens and that’s what I didn’t like. In the end I’ve made them
visible/discoverable by listing them in the Application Panel when the user
has admin rights.
3) Wiki descriptors are about configuration and I would find it normal
and good to
have them in the Main wiki’s administration screens too. This
means they could be accesssed both from the Wiki index screen ( point 1)
above) and from the Admin UI (point 2) above).
I agree thate there is no reason to choose a single place where you
can access the wiki descriptor, it's usefull in both sides. Not to be
mixed with the place where the descriptor itself is actually stored
which should remain in the main wiki for, I hope, obvious technical
reasons (one of them mentionned by Guillaume).
Thanks
-Vincent
> Moreover, it is very important to be able to modify a descriptor from
the
> main wiki instead of the subwiki, since if
you break it, you might be
> unable to access your subwiki anymore!
>
>
> 2014-11-06 11:10 GMT+01:00 Marius Dumitru Florea <
> mariusdumitru.florea(a)xwiki.com>gt;:
>
> > On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru
> > wrote:
> >
> > > The problem with the current place is that it is not really natural
and
> > > thus not very discoverable at all.
> >
> > I have this feeling to. I wanted to edit the descriptor of a subwiki a
> > few days ago and I was surprised I could find anything related in the
> > subwiki administration.
> >
> > > If you have to set the homepage, owner,
> > > etc of your wiki, you go to administration, but never to "wiki
index >
> > edit
> > > wiki".
> > >
> > > I believe that along this thread we have identified that these
settings
> > are
> > > valuable for both the main wiki and subwikis so this makes editing
the
> > wiki
> > > descriptor a valuable and deserving section to be introduced in
> > > administration, don`t you agree?
> > >
> > > Thanks,
> > > Eduard
> > >
> > > On Wed, Nov 5, 2014 at 4:38 PM, Guillaume "Louis-Marie" Delhumeau
<
> > > gdelhumeau(a)xwiki.com> wrote:
> > >
> > >> 2014-11-05 14:43 GMT+01:00 Eduard Moraru :
> > >>
> > >> > Concerning UC3 and UC4, we should not re-invent the wheel. I
have just
> > >> > remembered about the fact
that we already have the option of
setting
> > the
> > >> > homepage of a wiki exposed in the wiki's descriptor, so this
makes is
> > >> > already configurable.
> > >> >
> > >> > All we need to do now, is to expose this configuration further,
in
> > >> > Administration >
Configuration, under Wiki section (just like it
was
> > for
> > >> > workspaces, no idea why we removed it when refactoring to
'wikis'),
> > >>
> > >>
> > >> About this setting in particular it is because it is part of the
wiki
> > >> descriptor, and we now have
only one place to edit these
properties.
> > >>
> > >>
> > >> > where
> > >> > you can select what is the homepage of your current wiki.
Selecting
> > the
> > >> > owner and basically all the other stuff that you have in a wiki
> > >> descriptor
> > >> > should be done at this same level, since these are very important
> > >> > configurations that one needs to perform for either his main
wiki or
> > >> > subwiki.
> > >> >
> > >> > And no, the xwiki-platform-wiki module is not optional (it is
part of
> > the
> > >> > wiki model!), so no point in using a configurable class and
throwing
> > it
> > >> > back in the 'Applications' section.
> > >> >
> > >> > This actually goes along the lines of 'Proposal4: Set this
page
as
> > >> > homepage' [1], but
done in Administration, not on every page,
like
> > >> Vincent
> > >> > suggested.
> > >> >
> > >> > To get the homepage, apps need to do:
> > >> >
$services.wiki.getById($services.wiki.currentWikiId).mainPageReference
> > >> > Of course, this can be
improved to
> > >> > $services.wiki.currentWikiDescriptor.mainPageReference
> > >> >
> > >> > We will be still having the backwards compatibility concerns of
P4,
> > >> however
> > >> > I am sure that practical solutions (e.g. making Main.WebHome
redirect
> > to
> > >> >
> >
$services.wiki.getById($services.wiki.currentWikiId).mainPageReference,
> > >> > etc.) can be found if
problems arise in daily use.
> > >> >
> > >> > WDYT?
> > >> >
> > >> > ----------
> > >> > [1]
> > >> >
> > >> >
> > >>
> >
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal4Setthispag…
> > >> >
> > >> > On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET <
> > >> > jeremie.bousquet(a)gmail.com> wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > 2014-10-28 21:08 GMT+01:00 vincent(a)massol.net :
> > >> > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
> > >> > jeremie.bousquet(a)gmail.com
> > >> > > > (mailto:jeremie.bousquet@gmail.com)) wrote:
> > >> > > >
> > >> > > > > Hi,
> > >> > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a
écrit :
> > >> > > > > >
> > >> > > > > > Hi Vincent,
> > >> > > > > >
> > >> > > > > > On Mon, Oct 27, 2014 at 11:05 AM,
vincent(a)massol.net
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > > > Hi,
> > >> > > > > > >
> > >> > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru
(
> > >> enygma2002(a)gmail.com
> > >> > > > (mailto:
> > >> > > > > > > enygma2002(a)gmail.com)) wrote:
> > >> > > > > > >
> > >> > > > > > > > Hi,
> > >> > > > > > > >
> > >> > > > > > > > 2 new proposals (P6 and P7) have
been made recently.
I did
> > >> not
> > >> > > yet
> > >> > > > get
> > >> > > > > > > the
> > >> > > > > > > > chance to add comments/analysis on
them. Feel free
to do
> > it
> > >> in
> > >> > > the
> > >> > > > > > > > meanwhile if anybody wants to.
> > >> > > > > > > >
> > >> > > > > > > > A few notes on Jeremie's
"Proposal7:
DistrbutionWizard
> > sets
> > >> the
> > >> > > > > homepage
> > >> > > > > > > of
> > >> > > > > > > > a flavor and the Help App teaches
users" [2]:
> > >> > > > > > > >
> > >> > > > > > > > Personally, I find it a rather
elegant solution
based on
> > >> > > > separation of
> > >> > > > > > > > concerns. However, you need to be
aware that it is a
> > >> > medium/long
> > >> > > > term
> > >> > > > > > > > objective.
> > >> > > > > > > >
> > >> > > > > > > > The way I understood it is that we
delegate the task
of
> > >> > choosing
> > >> > > a
> > >> > > > > > > homepage
> > >> > > > > > > > to the DistributionWizard that will
most likely be in
> > charge
> > >> of
> > >> > > > > offering
> > >> > > > > > > > the user flavor options. At that
point, the homepage
of
> > the
> > >> > > current
> > >> > > > > wiki
> > >> > > > > > > > will be the homepage of the user
selected flavor.
> > Optionally,
> > >> > we
> > >> > > > can
> > >> > > > > also
> > >> > > > > > > > propose to use a blank page as
homepage if the user
wants,
> > >> > > however
> > >> > > > > this
> > >> > > > > > > > might be a bit of an overkill, since
the user can
easily
> > edit
> > >> > the
> > >> > > > page
> > >> > > > > > > and
> > >> > > > > > > > trash everything.
> > >> > > > > > >
> > >> > > > > > > The DW should not know at all about any
page. It
should be
> > up
> > >> to
> > >> > > the
> > >> > > > > > > flavor to define the wiki pages it will
contain and
install.
> > >> Each
> > >> > > > flavor
> > >> > > > > > > should propose its own home page.
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > Maybe I did not choose the best words, but the
way I
> > understood
> > >> it
> > >> > > (and
> > >> > > > > > tried to reformulate it) was not that the DW
explicitly
allows
> > >> you
> > >> > to
> > >> > > > > > select a homepage, but that indirectly,
through allowing
you
> > to
> > >> > > > install a
> > >> > > > > > flavor, it will additionally do the job
(again,
indirectly) of
> > >> > making
> > >> > > > you
> > >> > > > > > choose a homepage (through the flavor you have
selected).
> > >> > > > >
> > >> > > > > Yes that was the idea, possibly:
> > >> > > > > - DW doesn't have to know pages or set
homepage
> > >> > > > > - there could be a new wizard, similar to wizards
for new
page /
> > >> > space
> > >> > > > from
> > >> > > > > template, that allows choosing a kind of homepage
(empty,
wiki
> > >> > > concepts,
> > >> > > > > dashboard, etc)
> > >> > > > > - a flavor also adds its homepage as a possible
"template"
> > >> > > > > - btw it could be exactly the new space from
template
page, but
> > >> with
> > >> > > more
> > >> > > > > choices than current (empty / dashboard)
> > >> > > > > - following a dw run and a flavor installation,
this "new
Main
> > >> space
> > >> > > > > homepage from template" wizard is triggered
and displayed
(or
> > just
> > >> > > > proposed
> > >> > > > > to user through a button or link), and allows user
to
either
> > choose
> > >> > > > default
> > >> > > > > homepage of the flavor, or use another one
> > >> > > > > - current (or reworked) homepage is just the
default home
of the
> > >> > > default
> > >> > > > > flavor (which is the current XE xar)
> > >> > > >
> > >> > > > ok but:
> > >> > > >
> > >> > > > 1) it’s complex since it means that a flavor would need
to
> > register
> > >> > some
> > >> > > > kind of post install script to execute (which is
something we
> > don’t
> > >> > > really
> > >> > > > have)
> > >> > > >
> > >> > >
> > >> > > Depends, I was thinking more about a specific event like
"flavor
> > >> > installed"
> > >> > > or "extension installed" or "wiki installed /
updated". I'm not
> > sure to
> > >> > get
> > >> > > what you would need to do in this post install script ?
> > >> > > But it could be completely "manual" or just a link
at the end
of DW
> > to
> > >> > some
> > >> > > possible post-install stuff (like, consult help, manage home
page,
> > >> etc).
> > >> > >
> > >> > > I'd like to apologize here because my
"proposal" was more an
idea
> > than
> > >> a
> > >> > > well formalized proposal, even if it ended up in the list of
> > proposals,
> > >> > > it's obvious that it misses some thoughts and
clarifications... (I
> > >> > > understand your -1).
> > >> > >
> > >> > >
> > >> > > > 2) it negates a bit the point of a flavor which is to
propose a
> > >> defined
> > >> > > > “theme” and thus a defined home page matching that
theme
> > >> > > >
> > >> > >
> > >> > > Well, if you consider that current UI of XE is the default
xwiki
> > >> > "flavor",
> > >> > > this is exactly what it's about when we talk about
switching
home
> > page
> > >> > > easily, isn't it ? We want to let user set a home page
that
doesn't
> > >> match
> > >> > > the default theme freely. Obviously this default theme is not
very
> > >> > > "thematic"
as it's the default and should be versatile ...
> > >> > > Home page matching that theme could still be the mostly
recommended
> > >> > choice.
> > >> > > BTW a flavor, with such mechanism, could provide several
"home
page"
> > >> > > variants and not only
one, depending on the case.
> > >> > > If I take the case of a flavor based on the Mail archive (or
the
> > mail
> > >> > > archive extension alone, say), it already provides different
views
> > as
> > >> the
> > >> > > app home page (timeline, livetable, etc). Currently the
switch
is
> > done
> > >> > > through conditional include. Currently that app home page is
> > >> > > MailArchive.WebHome, if I could register it as a possible
home
page
> > >> > > template, it would
avoid having to rename it "Main.WebHome" to
make
> > it
> > >> a
> > >> > > flavor (and potentially destroy existing wiki home page by
mistake
> > when
> > >> > you
> > >> > > install that extension/flavor), and I could fullfill both
> > installation
> > >> > > use-cases (of using it as an app among others in some wiki,
and as a
> > >> > > wiki-wide-flavor in
another wiki or subwiki), from the same xar
> > bundled
> > >> > > app.
> > >> > > Again, here, I talk about possibilities and use-cases that
seem
> > logical
> > >> > or
> > >> > > interesting to me if I dig into my proposal, but I really
don't
> > know if
> > >> > > it's a good path or even a good idea for xwiki - I may
not
have the
> > big
> > >> > > picture :)
> > >> > > Also, the proposal certainly does not offer any solution for
> > short-term
> > >> > (if
> > >> > > you consider it provides options for long-term ;-) )
> > >> > >
> > >> > >
> > >> > > > 3) it doesn’t solve anything since once you select a
default
> > homepage
> > >> > you
> > >> > > > still need a way to change it afterwards if you want to
change it…
> > >> > > >
> > >> > >
> > >> > > There was the side-idea of the proposal (not well formulated,
maybe
> > was
> > >> > > just in my mind) that this wizard and/or DW could be
triggered
at
> > any
> > >> > later
> > >> > > time by an admin if he wants to replace homepage with some
other
> > >> > "default"
> > >> > > content. Maybe could be seen as a "personalization"
step
following a
> > >> new
> > >> > > wiki install or upgrade, but that could be triggered at any
later
> > time
> > >> to
> > >> > > "re-personalize" his wiki. I would put this then
also as a
feature
> > in
> > >> > admin
> > >> > > UI.
> > >> > > The difference with some other proposals, is that it would
not
be an
> > >> > action
> > >> > > available from the standard UI but limited to a post-install
step
> > and
> > >> the
> > >> > > admin UI (not like the variant below).
> > >> > >
> > >> > >
> > >> > > >
> > >> > > > I don’t see how this is much better than having a Admin
UI
> > allowing
> > >> you
> > >> > > to
> > >> > > > change the home page you wish to have. However it’s a
lot
more
> > >> complex
> > >> > > (and
> > >> > > > really marginally better).
> > >> > > >
> > >> > > > > Maybe instead of all this, it could be enough to
unrelate
the
> > "new
> > >> > > space"
> > >> > > > > and "apply space homepage template"
features ?
> > >> > > > > So I would just have to call "space / apply
template" to
replace
> > >> the
> > >> > > > > homepage of any space already existing (including
Main
> > obviously) ?
> > >> > > >
> > >> > > > Yes that’s better already IMO but then it should be a
menu
option
> > to
> > >> > > > replace any page content with a page template.
> > >> > > >
> > >> > >
> > >> > > I'm not sure if you talk about an additional option, or
an
option
> > that
> > >> > > would replace the "space /apply template" by a more
generic
"page /
> > >> apply
> > >> > > template", but I don't think anyway that a page
template is
the same
> > >> > thing
> > >> > > as a home page template (whether it's a space or wiki
home
page).
> > You'd
> > >> > > seldom want to use a blog post as a home page ...
> > >> > >
> > >> > > In this variant, there's still the question, if applying
such
> > template
> > >> is
> > >> > > considered an admin operation or not. If it's an admin
operation,
> > you
> > >> > also
> > >> > > proposed to start moving those admin actions to the admin UI,
which
> > is
> > >> -
> > >> > > sort of - what was my proposal about in first place :) (I
didn't
> > talk
> > >> > > specifically about admin UI at that time, but about avoiding
to
> > crowd
> > >> > > standard UI menus with unfrequent/admin operations).
> > >> > > That being said I don't think it's an admin action,
if you
need to
> > >> > protect
> > >> > > home page, as an admin you can set specific rights and forbid
this
> > >> "apply
> > >> > > template" to people that don't have those edit
rights. I'm not
sure
> > >> > editing
> > >> > > home page and applying a template should really be different
in
> > terms
> > >> of
> > >> > > privileges. But applying a template on an existing page or
home
> > page,
> > >> > seems
> > >> > > to be a rather unfrequent operation.
> > >> > >
> > >> > >
> > >> > > >
> > >> > > >
> > >> > > > Thanks
> > >> > > > -Vincent
> > >> > > >
> > >> > > > > > It was just a high level view on the direction
to
follow, and
> > >> not a
> > >> > > > > > specific technical aspect, so no reason to -1
it, right?
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > > BTW there’s also another variation for
the home page
that
> > >> hasn’t
> > >> > > been
> > >> > > > > > > discussed yet:
> > >> > > > > > > * Make the home page special by not
making it editable
(and
> > >> > without
> > >> > > > any
> > >> > > > > > > docextra tabs at the bottom). So no
rollback issue/edit
> > >> > weirdness.
> > >> > > > > > > * Only admins can change it and only
through the Admin
UI
> > >> > > (basically
> > >> > > > > > > decide which space home page to display
on the wiki
home
> > page).
> > >> > > > > > > * Somewhere in the content of the default
home page or
> > through
> > >> > the
> > >> > > > first
> > >> > > > > > > time wizard, direct the users to the
Sandbox page to
try it
> > out
> > >> > > > editing
> > >> > > > > > > (since this is what Sandbox is for!)
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > Adding this too and I think we`re good for
going forward
with
> > a
> > >> > vote,
> > >> > > > > since
> > >> > > > > > we have plenty of proposals.
> > >> > > > > >
> > >> > > > > > Thanks,
> > >> > > > > > Eduard
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > > Thanks
> > >> > > > > > > -Vincent
> > >> > > > > > >
> > >> > > > > > > > The task of teaching the user is
delegated
exclusively to
> > the
> > >> > > Help
> > >> > > > > > > > Application, with the note that the
application will
also
> > be
> > >> > > > proposed
> > >> > > > > to
> > >> > > > > > > > the user to be redirected to, as a
final step in the
DW
> > >> (after
> > >> > > the
> > >> > > > > > > > installation of the user selected
flavor is
complete).
> > >> > > > > > >
>
> > >> > > > > > > > All of this assumes that we have a
properly working
> > Flavors
> > >> > > feature
> > >> > > > > and
> > >> > > > > > > > Help Application. However, what
should we do in the
> > meanwhile
> > >> > for
> > >> > > > the
> > >> > > > > > > > default XWiki Enterprise UI / Flavor
/ build? Should
we
> > >> > postpone
> > >> > > > yet
> > >> > > > > > > again
> > >> > > > > > > > any work on the homepage until we
have the needed
> > elements to
> > >> > > > delegate
> > >> > > > > > > the
> > >> > > > > > > > problematic aspects, or should we do
something about
it in
> > >> the
> > >> > > > > meanwhile?
> > >> > > > > > > >
> > >> > > > > > > > Thanks,
> > >> > > > > > > > Eduard
> > >> > > > > > > >
> > >> > > > > > > > ----------
> > >> > > > > > > > [1]
> > >> > > >
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals
> > >> > > > > > >
> [2]
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbutio…
> > >> > > > > > >
>
> > >> > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM,
Guillaume
"Louis-Marie"
> > >> > > > Delhumeau <
> > >> > > > > > > > gdelhumeau(a)xwiki.com> wrote:
> > >> > > > > > > >
> > >> > > > > > > > > Hello.
> > >> > > > > > > > >
> > >> > > > > > > > > I have again a new argument
against using the
dashboard
> > and
> > >> > the
> > >> > > > > include
> > >> > > > > > > > > macro in the main page.
> > >> > > > > > > > >
> > >> > > > > > > > > When the user uses the
"Inline" editor to change
some
> > >> > gadgets,
> > >> > > > she
> > >> > > > > can
> > >> > > > > > > not
> > >> > > > > > > > > use the rollback action of the
main page to cancel
her
> > >> > changes.
> > >> > > > She
> > >> > > > > > > has to
> > >> > > > > > > > > go to the Dashboard page first,
and then rollback
her
>> changes
>> > > > from
>> > > > > > > there.
>> > > > > > > > >
>> > > > > > > > > Having an include macro in the default
page is
absolutely
>> not
>> > > > > > > intuitive,
>> > > > > > > > > even if you make it appears more
clearly.
>> > > > > > > > >
>> > > > > > > > > Thanks,
>> > > > > > > > > Guillaume
>> > > > _______________________________________________
>> > > > 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
>> > >
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>>
>>
>>
>> --
>> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>> _______________________________________________
>> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs