5 Dec
2010
5 Dec
'10
3:20 p.m.
Hi devs,
This is a buy one, get two proposal.
I propose that first we rename DocumentUpdateEvent and
DocumentSaveEvent to respectively DocumentUpdatedEvent and
DocumentCreatedEvent. Which would be both more clear and would comply
to the naming rules we've agreed on (see
http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I don't
mean real rename, but deprecation of the old events and creation of
two new ones.
Then I propose we introduce two new events : DocumentCreatingEvent and
DocumentUpdatingEvent, that would be fired before the actual save.
This is a pretty common use case for code that needs to hook on save
to perform any kind of verification/pre-computation/etc. This is the
same idea as the "preverify" method of the legacy notification
mechanism. The events would actually be fired from the same place as
the preverify method in old XWiki.java.
WDYT ?
I'm +1 and if we agree I volunteer to make those changes on 3.0 branch
- and maybe the 2.7 too if we agree we want that too (I do).
5 Dec
5 Dec
3:33 p.m.
New subject: [xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
On 12/05/2010 03:20 PM, Jerome Velociter wrote:
Hi devs,
This is a buy one, get two proposal.
I propose that first we rename DocumentUpdateEvent and
DocumentSaveEvent to respectively DocumentUpdatedEvent and
DocumentCreatedEvent. Which would be both more clear and would comply
to the naming rules we've agreed on (see
http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I don't
mean real rename, but deprecation of the old events and creation of
two new ones.
Then I propose we introduce two new events : DocumentCreatingEvent and
DocumentUpdatingEvent, that would be fired before the actual save.
This is a pretty common use case for code that needs to hook on save
to perform any kind of verification/pre-computation/etc. This is the
same idea as the "preverify" method of the legacy notification
mechanism. The events would actually be fired from the same place as
the preverify method in old XWiki.java.
WDYT ?
I'm +1 and if we agree I volunteer to make those changes on 3.0 branch
- and maybe the 2.7 too if we agree we want that too (I do).
+1, and +1 for 2.7.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
6 Dec
6 Dec
8:45 a.m.
New subject: [xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
On 12/05/2010 04:20 PM, Jerome Velociter wrote:
Hi devs,
This is a buy one, get two proposal.
I propose that first we rename DocumentUpdateEvent and
DocumentSaveEvent to respectively DocumentUpdatedEvent and
DocumentCreatedEvent. Which would be both more clear and would comply
to the naming rules we've agreed on (see
http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I don't
mean real rename, but deprecation of the old events and creation of
two new ones.
Then I propose we introduce two new events : DocumentCreatingEvent and
DocumentUpdatingEvent, that would be fired before the actual save.
This is a pretty common use case for code that needs to hook on save
to perform any kind of verification/pre-computation/etc. This is the
same idea as the "preverify" method of the legacy notification
mechanism. The events would actually be fired from the same place as
the preverify method in old XWiki.java.
WDYT ?
+1 for 3.0
+0 for 2.7
Thanks,
Marius
I'm +1 and if we agree I volunteer to make those changes on 3.0 branch
- and maybe the 2.7 too if we agree we want that too (I do).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:40 p.m.
New subject: [xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
On Sun, Dec 5, 2010 at 15:20, Jerome Velociter <jerome(a)xwiki.com> wrote:
Hi devs,
This is a buy one, get two proposal.
I propose that first we rename DocumentUpdateEvent and
DocumentSaveEvent to respectively DocumentUpdatedEvent and
DocumentCreatedEvent. Which would be both more clear and would comply
to the naming rules we've agreed on (see
http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I don't
mean real rename, but deprecation of the old events and creation of
two new ones.
Then I propose we introduce two new events : DocumentCreatingEvent and
DocumentUpdatingEvent, that would be fired before the actual save.
This is a pretty common use case for code that needs to hook on save
to perform any kind of verification/pre-computation/etc. This is the
same idea as the "preverify" method of the legacy notification
mechanism. The events would actually be fired from the same place as
the preverify method in old XWiki.java.
WDYT ?
I'm +1 and if we agree I volunteer to make those changes on 3.0 branch
- and maybe the 2.7 too if we agree we want that too (I do).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
-0 if you do only that ;)
If you start refactoring theses events it would be a good idea to also:
- move them to bridge module (we can't move them to model module since
theses events still send XWikiContext and XWikiDocument)
- refactor them to be based on references instead of strings
--
Thomas Mortagne
7 Dec
7 Dec
10:03 a.m.
New subject: [xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
On Mon, Dec 6, 2010 at 3:40 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Sun, Dec 5, 2010 at 15:20, Jerome Velociter
<jerome(a)xwiki.com> wrote:
Fair enough :)
Hi devs,
This is a buy one, get two proposal.
I propose that first we rename DocumentUpdateEvent and
DocumentSaveEvent to respectively DocumentUpdatedEvent and
DocumentCreatedEvent. Which would be both more clear and would comply
to the naming rules we've agreed on (see
http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I don't
mean real rename, but deprecation of the old events and creation of
two new ones.
Then I propose we introduce two new events : DocumentCreatingEvent and
DocumentUpdatingEvent, that would be fired before the actual save.
This is a pretty common use case for code that needs to hook on save
to perform any kind of verification/pre-computation/etc. This is the
same idea as the "preverify" method of the legacy notification
mechanism. The events would actually be fired from the same place as
the preverify method in old XWiki.java.
WDYT ?
I'm +1 and if we agree I volunteer to make those changes on 3.0 branch
- and maybe the 2.7 too if we agree we want that too (I do).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
-0 if you do only that ;)
If you start refactoring theses events it would be a
good idea to also:
- move them to bridge module (we can't move them to model module since
theses events still send XWikiContext and XWikiDocument)
- refactor them to be based on references instead of strings
OK.
One more question : are you guys OK to maintain compatibility for the events
to be deprecated in an aspect ?
(+1 from me)
Jerome.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:49 a.m.
New subject: [xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
On Tue, Dec 7, 2010 at 10:03, Jerome Velociter <jerome(a)xwiki.com> wrote:
On Mon, Dec 6, 2010 at 3:40 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Aspect I don't know but we need to have something listening to new
events and generating old events (not sure what is doable with an
aspect).
Also I think old events and bridge I described should be moved in some
"xwiki-legacy" module or something like that to clean up observation
module. That way components already built will work inside XWiki but
will need to be refactored when core dependency is upgraded.
On Sun, Dec 5, 2010 at 15:20, Jerome Velociter
<jerome(a)xwiki.com> wrote:
Fair enough :)
Hi devs,
This is a buy one, get two proposal.
I propose that first we rename DocumentUpdateEvent and
DocumentSaveEvent to respectively DocumentUpdatedEvent and
DocumentCreatedEvent. Which would be both more clear and would comply
to the naming rules we've agreed on (see
http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I don't
mean real rename, but deprecation of the old events and creation of
two new ones.
Then I propose we introduce two new events : DocumentCreatingEvent and
DocumentUpdatingEvent, that would be fired before the actual save.
This is a pretty common use case for code that needs to hook on save
to perform any kind of verification/pre-computation/etc. This is the
same idea as the "preverify" method of the legacy notification
mechanism. The events would actually be fired from the same place as
the preverify method in old XWiki.java.
WDYT ?
I'm +1 and if we agree I volunteer to make those changes on 3.0 branch
- and maybe the 2.7 too if we agree we want that too (I do).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
-0 if you do only that ;)
If you start refactoring theses events it would
be a good idea to also:
- move them to bridge module (we can't move them to model module since
theses events still send XWikiContext and XWikiDocument)
- refactor them to be based on references instead of strings
OK.
One more question : are you guys OK to maintain compatibility for the events
to be deprecated in an aspect ?
(+1 from me)
Jerome.
--
Thomas Mortagne
--
Thomas Mortagne
_______________________________________________
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
11:24 a.m.
New subject: [xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
On Tue, Dec 7, 2010 at 10:49 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Tue, Dec 7, 2010 at 10:03, Jerome Velociter
<jerome(a)xwiki.com> wrote:
Fair enough :)
events
Old events OK, but new bridge events should rather go in bridge module no ?
Or am I misunderstanding something ?
Jerome.
On Mon, Dec 6, 2010 at 3:40 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Sun, Dec 5, 2010 at 15:20, Jerome Velociter <jerome(a)xwiki.com>
wrote:
> > Hi devs,
> >
> > This is a buy one, get two proposal.
> >
> > I propose that first we rename DocumentUpdateEvent and
> > DocumentSaveEvent to respectively DocumentUpdatedEvent and
> > DocumentCreatedEvent. Which would be both more clear and would comply
> > to the naming rules we've agreed on (see
> > http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I
don't
mean real rename, but deprecation of the old events
and creation of
two new ones.
Then I propose we introduce two new events : DocumentCreatingEvent and
DocumentUpdatingEvent, that would be fired before the actual save.
This is a pretty common use case for code that needs to hook on save
to perform any kind of verification/pre-computation/etc. This is the
same idea as the "preverify" method of the legacy notification
mechanism. The events would actually be fired from the same place as
the preverify method in old XWiki.java.
WDYT ?
I'm +1 and if we agree I volunteer to make those changes on 3.0 branch
- and maybe the 2.7 too if we agree we want that too (I do).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
-0 if you do only that ;)
If you start refactoring theses events it would
be a good idea to also:
- move them to bridge module (we can't move them to model module since
theses events still send XWikiContext and XWikiDocument)
- refactor them to be based on references instead of strings
OK.
One more question : are you guys OK to maintain compatibility for the to be deprecated in an aspect ?
(+1 from me)
Aspect I don't know but we need to have something listening to new
events and generating old events (not sure what is doable with an
aspect).
Also I think old events and bridge I described should be moved in some
"xwiki-legacy" module or something like that to clean up observation
module. That way components already built will work inside
XWiki but
will need to be refactored when core dependency is upgraded.
Jerome.
--
Thomas Mortagne
_______________________________________________
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:50 a.m.
New subject: [xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
On Tue, Dec 7, 2010 at 11:24, Jerome Velociter <jerome(a)xwiki.com> wrote:
On Tue, Dec 7, 2010 at 10:49 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
What I called "bridge" here is the component listening to new events
and generating old events. This component should go in "xwiki-legacy"
since it only make sense if you have old events.
As I said new events should go in core-bridge module.
On Tue, Dec 7, 2010 at 10:03, Jerome Velociter
<jerome(a)xwiki.com> wrote:
events
Old events OK, but new bridge events should rather go in bridge module no ?
Or am I misunderstanding something ? On Mon, Dec 6, 2010 at 3:40 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Sun, Dec 5, 2010 at 15:20, Jerome Velociter <jerome(a)xwiki.com>
wrote:
> > Hi devs,
> >
> > This is a buy one, get two proposal.
> >
> > I propose that first we rename DocumentUpdateEvent and
> > DocumentSaveEvent to respectively DocumentUpdatedEvent and
> > DocumentCreatedEvent. Which would be both more clear and would comply
> > to the naming rules we've agreed on (see
> > http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I
don't
> mean
real rename, but deprecation of the old events and creation of
> two new ones.
>
> Then I propose we introduce two new events : DocumentCreatingEvent and
> DocumentUpdatingEvent, that would be fired before the actual save.
> This is a pretty common use case for code that needs to hook on save
> to perform any kind of verification/pre-computation/etc. This is the
> same idea as the "preverify" method of the legacy notification
> mechanism. The events would actually be fired from the same place as
> the preverify method in old XWiki.java.
>
> WDYT ?
>
> I'm +1 and if we agree I volunteer to make those changes on 3.0 branch
> - and maybe the 2.7 too if we agree we want that too (I do).
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
-0 if you do only that ;)
Fair enough :)
If you start refactoring theses events it would
be a good idea to also:
- move them to bridge module (we can't move them to model module since
theses events still send XWikiContext and XWikiDocument)
- refactor them to be based on references instead of strings
OK.
One more question : are you guys OK to maintain compatibility for the to be deprecated in an aspect ?
(+1 from me)
Aspect I don't know but we need to have something listening to new
events and generating old events (not sure what is doable with an
aspect).
Also I think old events and bridge I described should be moved in some
"xwiki-legacy" module or something like that to clean up observation
module.
Jerome.
--
Thomas Mortagne
That way components already built will work
inside XWiki but
will need to be refactored when core dependency is upgraded.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Jerome.
--
Thomas Mortagne
_______________________________________________
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:02 p.m.
New subject: [xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
OK makes sense now.
I'll investigate that bridge. Should be possible with an aspect I think (you
can define pointcuts that catches constructor calls with aspectj) - but
maybe that's not the best solution.
Jerome.
On Tue, Dec 7, 2010 at 11:50 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Tue, Dec 7, 2010 at 11:24, Jerome Velociter
<jerome(a)xwiki.com> wrote:
Old events OK, but new bridge events should rather go in bridge module no ?
On Tue, Dec 7, 2010 at 10:49 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Tue, Dec 7, 2010 at 10:03, Jerome Velociter <jerome(a)xwiki.com>
wrote:
> > On Mon, Dec 6, 2010 at 3:40 PM, Thomas
Mortagne
> > <thomas.mortagne(a)xwiki.com>wrote;wrote:
> >
> >> On Sun, Dec 5, 2010 at 15:20, Jerome Velociter <jerome(a)xwiki.com>
> wrote:
> >> > Hi devs,
> >> >
> >> > This is a buy one, get two proposal.
> >> >
> >> > I propose that first we rename DocumentUpdateEvent and
> >> > DocumentSaveEvent to respectively DocumentUpdatedEvent and
> >> > DocumentCreatedEvent. Which would be both more clear and would
comply
> >> > to the naming rules we've
agreed on (see
> >> > http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I
> don't
> >> > mean real rename, but deprecation of the old events and creation of
> >> > two new ones.
> >> >
> >> > Then I propose we introduce two new events : DocumentCreatingEvent
and
> >> > DocumentUpdatingEvent, that
would be fired before the actual save.
> >> > This is a pretty common use case for code that needs to hook on
save
> >> > to perform any kind of
verification/pre-computation/etc. This is
the
> >> > same idea as the
"preverify" method of the legacy notification
> >> > mechanism. The events would actually be fired from the same place
as
> >> > the preverify method in old
XWiki.java.
> >> >
> >> > WDYT ?
> >> >
> >> > I'm +1 and if we agree I volunteer to make those changes on 3.0
branch
> >> > - and maybe the 2.7 too if we
agree we want that too (I do).
> >> > _______________________________________________
> >> > devs mailing list
> >> > devs(a)xwiki.org
> >> > http://lists.xwiki.org/mailman/listinfo/devs
> >> >
> >>
> >> -0 if you do only that ;)
> >>
> >
> > Fair enough :)
> >
> >
> >> If you start refactoring theses events it would be a good idea to
also:
> >> - move them to bridge module (we
can't move them to model module
since
> theses events still send XWikiContext and
XWikiDocument)
> - refactor them to be based on references instead of strings
>
OK.
One more question : are you guys OK to maintain compatibility for the
events
to be deprecated in an aspect ?
(+1 from me)
Aspect I don't know but we need to have something listening to new
events and generating old events (not sure what is doable with an
aspect).
Also I think old events and bridge I described should be moved in some
"xwiki-legacy" module or something like that to clean up observation
module.
Or am I misunderstanding something ?
What I called "bridge" here is the component listening to new events
and generating old events. This component should go in "xwiki-legacy"
since it only make sense if you have old events.
As I said new events should go in core-bridge module.
Jerome.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
That way components already built will work
inside XWiki but
will need to be refactored when core dependency is upgraded.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Jerome.
>
> --
> Thomas Mortagne
> _______________________________________________
> 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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:33 p.m.
New subject: [xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
On Tue, Dec 7, 2010 at 12:02, Jerome Velociter <jerome(a)xwiki.com> wrote:
OK makes sense now.
I'll investigate that bridge. Should be possible with an aspect I think (you
can define pointcuts that catches constructor calls with aspectj) - but
maybe that's not the best solution.
My POV is that if we have a separated xwiki-legacy module there is no
need to do an aspect, it's a lot easier to simply write a java
component.
Jerome.
On Tue, Dec 7, 2010 at 11:50 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Thomas Mortagne
On Tue, Dec 7, 2010 at 11:24, Jerome Velociter
<jerome(a)xwiki.com> wrote:
?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Dec 7, 2010 at 10:49 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Tue, Dec 7, 2010 at 10:03, Jerome Velociter <jerome(a)xwiki.com>
wrote:
> > On Mon, Dec 6, 2010 at 3:40 PM, Thomas
Mortagne
> > <thomas.mortagne(a)xwiki.com>wrote;wrote:
> >
> >> On Sun, Dec 5, 2010 at 15:20, Jerome Velociter <jerome(a)xwiki.com>
> wrote:
> >> > Hi devs,
> >> >
> >> > This is a buy one, get two proposal.
> >> >
> >> > I propose that first we rename DocumentUpdateEvent and
> >> > DocumentSaveEvent to respectively DocumentUpdatedEvent and
> >> > DocumentCreatedEvent. Which would be both more clear and would
comply
> >> > to the naming rules we've
agreed on (see
> >> > http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I
> don't
> >> > mean real rename, but deprecation of the old events and creation of
> >> > two new ones.
> >> >
> >> > Then I propose we introduce two new events : DocumentCreatingEvent
and
> >> > DocumentUpdatingEvent, that
would be fired before the actual save.
> >> > This is a pretty common use case for code that needs to hook on
save
> >> > to perform any kind of
verification/pre-computation/etc. This is
the
> >> > same idea as the
"preverify" method of the legacy notification
> >> > mechanism. The events would actually be fired from the same place
as
> >> > the preverify method in old
XWiki.java.
> >> >
> >> > WDYT ?
> >> >
> >> > I'm +1 and if we agree I volunteer to make those changes on 3.0
branch
> >> > - and maybe the 2.7 too if we
agree we want that too (I do).
> >> > _______________________________________________
> >> > devs mailing list
> >> > devs(a)xwiki.org
> >> > http://lists.xwiki.org/mailman/listinfo/devs
> >> >
> >>
> >> -0 if you do only that ;)
> >>
> >
> > Fair enough :)
> >
> >
> >> If you start refactoring theses events it would be a good idea to
also:
> >> - move them to bridge module (we
can't move them to model module
since
>>
theses events still send XWikiContext and XWikiDocument)
>> - refactor them to be based on references instead of strings
>>
>
> OK.
>
> One more question : are you guys OK to maintain compatibility for the
events
> to be deprecated in an aspect ?
>
> (+1 from me)
Aspect I don't know but we need to have something listening to new
events and generating old events (not sure what is doable with an
aspect).
Also I think old events and bridge I described should be moved in some
"xwiki-legacy" module or something like that to clean up observation
module.
Old events OK, but new bridge events should rather go in bridge module no
Or am I misunderstanding something ?
What I called "bridge" here is the component listening to new events
and generating old events. This component should go in "xwiki-legacy"
since it only make sense if you have old events.
As I said new events should go in core-bridge module.
Jerome.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
That way components already built will work
inside XWiki but
will need to be refactored when core dependency is upgraded.
>
> Jerome.
>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> 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
>
--
Thomas Mortagne
_______________________________________________
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
5442
days inactive
5444
days old
9 comments
4 participants
participants (4)
-
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne