upgrade to gwt 1.4

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

upgrade to gwt 1.4

lucaa
Hi all,

we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since
gwttk does not have a version for gwt 1.4 and we depend on it for creating
modal dialogs, we need to replace tk with something else. A good option is
gwt-ext, which also can replace gwt-widgets and provides some more nice ui
objects and client functionality (like date parsing -- which we get from
gwt-widgets for the moment).
The trouble with gwt-ext is that it requires ext javascript library to
run, which means that any gwt application needs to import, besides the
gwt.js file, some ext javascript files. Since the modal dialogs are
defined in the web-gwt module (so our gwt-ext dependency is there) and we
cannot import the ext javascript files at that level, the only solution is
to rely on the application using web-gwt to include right all required
files. It doesn't seem to me as good practice but I cannot figure out how
big of an issue it is (since that application already has some rules to
obey, js files to include, etc to have gwt working).

WDYT?


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: upgrade to gwt 1.4

Jerome Velociter
> Hi all,
>
> we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since
> gwttk does not have a version for gwt 1.4 and we depend on it for creating
> modal dialogs, we need to replace tk with something else. A good option is
> gwt-ext, which also can replace gwt-widgets and provides some more nice ui
> objects and client functionality (like date parsing -- which we get from
> gwt-widgets for the moment).
> The trouble with gwt-ext is that it requires ext javascript library to
> run, which means that any gwt application needs to import, besides the
> gwt.js file, some ext javascript files. Since the modal dialogs are
> defined in the web-gwt module (so our gwt-ext dependency is there) and we
> cannot import the ext javascript files at that level, the only solution is
> to rely on the application using web-gwt to include right all required
> files. It doesn't seem to me as good practice but I cannot figure out how
> big of an issue it is (since that application already has some rules to
> obey, js files to include, etc to have gwt working).
>
IMO,

Pros for migrating to ext, vs. sticking to gwttk:
- larger community, visibility on roadmap
- lots of widgets/functionnalities available (datepickers, form
validation, etc.)
- gwt 1.4 already compatible

Cons:
- every app has to import ext JS scripts in addition to gwt.js
- increases total JS size

It would be great to have opinions from the Curriki development team on
the topic.

Regards,
Jerome.

> WDYT?
>
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: upgrade to gwt 1.4

kaaloo
Hi Jérôme,

You might also consider MyGWT:

http://mygwt.net/

if you're worried about the ext.js lib.  It's a native implementation.

For Curriki, there may be some issues with gwt-html-editor which in
its 1.4 branch just brings up Fck Editor.  I had some issues using
gwt-html-editor trunk in 1.4.61.

Luis.

On Jan 14, 2008 9:55 AM, Jerome Velociter <[hidden email]> wrote:

> > Hi all,
> >
> > we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since
> > gwttk does not have a version for gwt 1.4 and we depend on it for creating
> > modal dialogs, we need to replace tk with something else. A good option is
> > gwt-ext, which also can replace gwt-widgets and provides some more nice ui
> > objects and client functionality (like date parsing -- which we get from
> > gwt-widgets for the moment).
> > The trouble with gwt-ext is that it requires ext javascript library to
> > run, which means that any gwt application needs to import, besides the
> > gwt.js file, some ext javascript files. Since the modal dialogs are
> > defined in the web-gwt module (so our gwt-ext dependency is there) and we
> > cannot import the ext javascript files at that level, the only solution is
> > to rely on the application using web-gwt to include right all required
> > files. It doesn't seem to me as good practice but I cannot figure out how
> > big of an issue it is (since that application already has some rules to
> > obey, js files to include, etc to have gwt working).
> >
> IMO,
>
> Pros for migrating to ext, vs. sticking to gwttk:
> - larger community, visibility on roadmap
> - lots of widgets/functionnalities available (datepickers, form
> validation, etc.)
> - gwt 1.4 already compatible
>
> Cons:
> - every app has to import ext JS scripts in addition to gwt.js
> - increases total JS size
>
> It would be great to have opinions from the Curriki development team on
> the topic.
>
> Regards,
> Jerome.
>
>
> > WDYT?
> >
> >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Luis Arias
+33 6 14 20 87 93
skype : kaaloo
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: upgrade to gwt 1.4

lucaa
> Hi Jérôme,
>
> You might also consider MyGWT:
>
> http://mygwt.net/

I checked it out, it has a lot of nice features, but, unfortunately, no
'date picker' widget (which is one of the reasons we started all this
gwt-ext + gwt1.4 thing).
So yes, we could use it, but it will not fully replace gwt-ext and fulfill
our needs.

>
> if you're worried about the ext.js lib.  It's a native implementation.
>
> For Curriki, there may be some issues with gwt-html-editor which in
> its 1.4 branch just brings up Fck Editor.  I had some issues using
> gwt-html-editor trunk in 1.4.61.

So we definitely need an opinion from Curriki on this...

>
> Luis.
>
> On Jan 14, 2008 9:55 AM, Jerome Velociter <[hidden email]> wrote:
>
>> > Hi all,
>> >
>> > we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so,
>> since
>> > gwttk does not have a version for gwt 1.4 and we depend on it for
>> creating
>> > modal dialogs, we need to replace tk with something else. A good
>> option is
>> > gwt-ext, which also can replace gwt-widgets and provides some more
>> nice ui
>> > objects and client functionality (like date parsing -- which we get
>> from
>> > gwt-widgets for the moment).
>> > The trouble with gwt-ext is that it requires ext javascript library to
>> > run, which means that any gwt application needs to import, besides the
>> > gwt.js file, some ext javascript files. Since the modal dialogs are
>> > defined in the web-gwt module (so our gwt-ext dependency is there) and
>> we
>> > cannot import the ext javascript files at that level, the only
>> solution is
>> > to rely on the application using web-gwt to include right all required
>> > files. It doesn't seem to me as good practice but I cannot figure out
>> how
>> > big of an issue it is (since that application already has some rules
>> to
>> > obey, js files to include, etc to have gwt working).
>> >
>> IMO,
>>
>> Pros for migrating to ext, vs. sticking to gwttk:
>> - larger community, visibility on roadmap
>> - lots of widgets/functionnalities available (datepickers, form
>> validation, etc.)
>> - gwt 1.4 already compatible
>>
>> Cons:
>> - every app has to import ext JS scripts in addition to gwt.js
>> - increases total JS size
>>
>> It would be great to have opinions from the Curriki development team on
>> the topic.
>>
>> Regards,
>> Jerome.
>>
>>
>> > WDYT?
>> >
>> >
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>>
>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Luis Arias
> +33 6 14 20 87 93
> skype : kaaloo
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: upgrade to gwt 1.4

Sachin Mittal
In reply to this post by lucaa
I would suggest to have extjs implemented for ajax.
Reasons already mentioned below.
File size is not an issue as it needs to be loaded only once.

I have done some work on albatross skin to replace the default template layout with extjs border layout for my local wiki.

One thing you need to take care is that there may be some other js files whose execution might conflict with ext-base.js execution.
For my implementation I had to comment out all the other js that were getting loaded.

Also another cool thing would be to integration extjs with jquery. This combination can lead to some rich UI.

I have not yet tested the gwt web interface with xwiki, but not sure if anyone has combined extjs with gwt, also from the version 2.0 of extjs I don't see any adapter for gwt.

Thanks
Sachin



 

----------------------------------------------------------------------

Message: 1
Date: Mon, 14 Jan 2008 21:31:38 +0100
From: "Luis Arias" <[hidden email] >
Subject: Re: [xwiki-devs] upgrade to gwt 1.4
To: "XWiki Developers" <[hidden email]>
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset=UTF-8

Hi J?r?me,

You might also consider MyGWT:

http://mygwt.net/

if you're worried about the ext.js lib.  It's a native implementation.

For Curriki, there may be some issues with gwt-html-editor which in
its 1.4 branch just brings up Fck Editor.  I had some issues using
gwt-html-editor trunk in 1.4.61.

Luis.

On Jan 14, 2008 9:55 AM, Jerome Velociter <[hidden email]> wrote:

> > Hi all,
> >
> > we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since
> > gwttk does not have a version for gwt 1.4 and we depend on it for creating
> > modal dialogs, we need to replace tk with something else. A good option is
> > gwt-ext, which also can replace gwt-widgets and provides some more nice ui
> > objects and client functionality (like date parsing -- which we get from
> > gwt-widgets for the moment).
> > The trouble with gwt-ext is that it requires ext javascript library to
> > run, which means that any gwt application needs to import, besides the
> > gwt.js file, some ext javascript files. Since the modal dialogs are
> > defined in the web-gwt module (so our gwt-ext dependency is there) and we
> > cannot import the ext javascript files at that level, the only solution is
> > to rely on the application using web-gwt to include right all required
> > files. It doesn't seem to me as good practice but I cannot figure out how
> > big of an issue it is (since that application already has some rules to
> > obey, js files to include, etc to have gwt working).
> >
> IMO,
>
> Pros for migrating to ext, vs. sticking to gwttk:
> - larger community, visibility on roadmap
> - lots of widgets/functionnalities available (datepickers, form
> validation, etc.)
> - gwt 1.4 already compatible
>
> Cons:
> - every app has to import ext JS scripts in addition to gwt.js
> - increases total JS size
>
> It would be great to have opinions from the Curriki development team on
> the topic.
>
> Regards,
> Jerome.
>
>
> > WDYT?
> >
> >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Luis Arias
+33 6 14 20 87 93
skype : kaaloo

------------------------------



_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: upgrade to gwt 1.4

lucaa
In reply to this post by lucaa
Hi everybody,

Jerome suggested yesterday that we could handle the upgrade as follows:
- use MyGWT widgets library for the web-gwt functionalities (modal dialog
boxes) since it is a pure java library and its usage only involves changes
in the web-gwt code
- if needed, gwt-ext could be used for particular projects using web-gwt
api and each project's code could be changed accordingly (this would be
the case for watch).

Both libraries seem pretty reliable, with active developers and nice
community, so, from this point of view, they are both superior to gwttk
that we currently use.

Here's my +1 for this approach.

WDYT?


> Hi all,
>
> we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since
> gwttk does not have a version for gwt 1.4 and we depend on it for creating
> modal dialogs, we need to replace tk with something else. A good option is
> gwt-ext, which also can replace gwt-widgets and provides some more nice ui
> objects and client functionality (like date parsing -- which we get from
> gwt-widgets for the moment).
> The trouble with gwt-ext is that it requires ext javascript library to
> run, which means that any gwt application needs to import, besides the
> gwt.js file, some ext javascript files. Since the modal dialogs are
> defined in the web-gwt module (so our gwt-ext dependency is there) and we
> cannot import the ext javascript files at that level, the only solution is
> to rely on the application using web-gwt to include right all required
> files. It doesn't seem to me as good practice but I cannot figure out how
> big of an issue it is (since that application already has some rules to
> obey, js files to include, etc to have gwt working).
>
> WDYT?
>
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: upgrade to gwt 1.4

Guillaume Lerouge
Non-binding +1 from me too... Eager to have XWatch benefit from the results of this work :-)

Guillaume

On 17/01/2008, [hidden email] <[hidden email]> wrote:
Hi everybody,

Jerome suggested yesterday that we could handle the upgrade as follows:
- use MyGWT widgets library for the web-gwt functionalities (modal dialog
boxes) since it is a pure java library and its usage only involves changes
in the web-gwt code
- if needed, gwt-ext could be used for particular projects using web-gwt
api and each project's code could be changed accordingly (this would be
the case for watch).

Both libraries seem pretty reliable, with active developers and nice
community, so, from this point of view, they are both superior to gwttk
that we currently use.

Here's my +1 for this approach.

WDYT?


> Hi all,
>
> we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since
> gwttk does not have a version for gwt 1.4 and we depend on it for creating
> modal dialogs, we need to replace tk with something else. A good option is
> gwt-ext, which also can replace gwt-widgets and provides some more nice ui
> objects and client functionality (like date parsing -- which we get from
> gwt-widgets for the moment).
> The trouble with gwt-ext is that it requires ext javascript library to
> run, which means that any gwt application needs to import, besides the
> gwt.js file, some ext javascript files. Since the modal dialogs are
> defined in the web-gwt module (so our gwt-ext dependency is there) and we
> cannot import the ext javascript files at that level, the only solution is
> to rely on the application using web-gwt to include right all required
> files. It doesn't seem to me as good practice but I cannot figure out how
> big of an issue it is (since that application already has some rules to
> obey, js files to include, etc to have gwt working).
>
> WDYT?
>
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs



--
http://wikibc.blogspot.com/

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: upgrade to gwt 1.4

Sergiu Dumitriu-2
In reply to this post by lucaa
[hidden email] wrote:

> Hi everybody,
>
> Jerome suggested yesterday that we could handle the upgrade as follows:
> - use MyGWT widgets library for the web-gwt functionalities (modal dialog
> boxes) since it is a pure java library and its usage only involves changes
> in the web-gwt code
> - if needed, gwt-ext could be used for particular projects using web-gwt
> api and each project's code could be changed accordingly (this would be
> the case for watch).
>
> Both libraries seem pretty reliable, with active developers and nice
> community, so, from this point of view, they are both superior to gwttk
> that we currently use.
>
> Here's my +1 for this approach.
>
> WDYT?
>
>
>> Hi all,
>>
>> we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since
>> gwttk does not have a version for gwt 1.4 and we depend on it for creating
>> modal dialogs, we need to replace tk with something else. A good option is
>> gwt-ext, which also can replace gwt-widgets and provides some more nice ui
>> objects and client functionality (like date parsing -- which we get from
>> gwt-widgets for the moment).
>> The trouble with gwt-ext is that it requires ext javascript library to
>> run, which means that any gwt application needs to import, besides the
>> gwt.js file, some ext javascript files. Since the modal dialogs are
>> defined in the web-gwt module (so our gwt-ext dependency is there) and we
>> cannot import the ext javascript files at that level, the only solution is
>> to rely on the application using web-gwt to include right all required
>> files. It doesn't seem to me as good practice but I cannot figure out how
>> big of an issue it is (since that application already has some rules to
>> obey, js files to include, etc to have gwt working).
>>
>> WDYT?
>>
>>

Hi,

I think that the most important think is that updating the products
using gwt should be as easy as possible. The two products that
intensively use gwt are Watch and Curriki, and since you are a Watch
developer, can you try the upgrade and see how much time it takes to
update the failing code? Curriki is already on a tight deadline, so I'm
sure they won't like long delays (however, they are still using an older
branch, so they won't be affected by the trunk update yet).

Sergiu
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: upgrade to gwt 1.4

lucaa
> [hidden email] wrote:
>> Hi everybody,
>>
>> Jerome suggested yesterday that we could handle the upgrade as follows:
>> - use MyGWT widgets library for the web-gwt functionalities (modal
>> dialog
>> boxes) since it is a pure java library and its usage only involves
>> changes
>> in the web-gwt code
>> - if needed, gwt-ext could be used for particular projects using web-gwt
>> api and each project's code could be changed accordingly (this would be
>> the case for watch).
>>
>> Both libraries seem pretty reliable, with active developers and nice
>> community, so, from this point of view, they are both superior to gwttk
>> that we currently use.
>>
>> Here's my +1 for this approach.
>>
>> WDYT?
>>
>>
>>> Hi all,
>>>
>>> we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so,
>>> since
>>> gwttk does not have a version for gwt 1.4 and we depend on it for
>>> creating
>>> modal dialogs, we need to replace tk with something else. A good option
>>> is
>>> gwt-ext, which also can replace gwt-widgets and provides some more nice
>>> ui
>>> objects and client functionality (like date parsing -- which we get
>>> from
>>> gwt-widgets for the moment).
>>> The trouble with gwt-ext is that it requires ext javascript library to
>>> run, which means that any gwt application needs to import, besides the
>>> gwt.js file, some ext javascript files. Since the modal dialogs are
>>> defined in the web-gwt module (so our gwt-ext dependency is there) and
>>> we
>>> cannot import the ext javascript files at that level, the only solution
>>> is
>>> to rely on the application using web-gwt to include right all required
>>> files. It doesn't seem to me as good practice but I cannot figure out
>>> how
>>> big of an issue it is (since that application already has some rules to
>>> obey, js files to include, etc to have gwt working).
>>>
>>> WDYT?
>>>
>>>
>
> Hi,
>
> I think that the most important think is that updating the products
> using gwt should be as easy as possible. The two products that
> intensively use gwt are Watch and Curriki, and since you are a Watch
> developer, can you try the upgrade and see how much time it takes to
> update the failing code?

I already did that with gwt-ext, the changes don't take long at all (6-8
hours, maybe) and they can be done in a transparent manner, without
impacting for the code that uses them, except, of course for some
appearance changes which are inevitable. There is also some testing to be
done to ensure that no behaviour was changed which might also take some
time.

The problem with the projects using gwt code is that we would also upgrade
gwt to gwt 1.4 and they must handle their own dependencies and resolve any
code failing due to API breaking changes (which are not too many,
actually). While XWiki Watch is OK from this point of view I don't know
anything about Curriki yet.

> Curriki is already on a tight deadline, so I'm
> sure they won't like long delays (however, they are still using an older
> branch, so they won't be affected by the trunk update yet).
>
> Sergiu
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: upgrade to gwt 1.4

Ludovic Dubost-2

Hi,

Curriki is currently running on the 1.1 branch. There is a possibility
to move to the 1.2 branch for Curriki 1.5.1 (released in the next few
weeks).
Moving to gwt 1.4 is definitively in the plan for 1.6 to especially
benefit from performance improvements.
Curriki uses gwttk dialogs so would need to switch to other dialogs.
There are no big needs of gwt-ext capabilities but I'm sure we can find
uses for it afterwards.

So from the Curriki point of view +1 to move to 1.4 and use MyGWT for
modial dialogs and gwt-ext for more extensive features, as long as all
this is in the 1.3 branch.

 From my point of view +1 also

Ludovic

[hidden email] wrote:

>> [hidden email] wrote:
>>    
>>> Hi everybody,
>>>
>>> Jerome suggested yesterday that we could handle the upgrade as follows:
>>> - use MyGWT widgets library for the web-gwt functionalities (modal
>>> dialog
>>> boxes) since it is a pure java library and its usage only involves
>>> changes
>>> in the web-gwt code
>>> - if needed, gwt-ext could be used for particular projects using web-gwt
>>> api and each project's code could be changed accordingly (this would be
>>> the case for watch).
>>>
>>> Both libraries seem pretty reliable, with active developers and nice
>>> community, so, from this point of view, they are both superior to gwttk
>>> that we currently use.
>>>
>>> Here's my +1 for this approach.
>>>
>>> WDYT?
>>>
>>>
>>>      
>>>> Hi all,
>>>>
>>>> we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so,
>>>> since
>>>> gwttk does not have a version for gwt 1.4 and we depend on it for
>>>> creating
>>>> modal dialogs, we need to replace tk with something else. A good option
>>>> is
>>>> gwt-ext, which also can replace gwt-widgets and provides some more nice
>>>> ui
>>>> objects and client functionality (like date parsing -- which we get
>>>> from
>>>> gwt-widgets for the moment).
>>>> The trouble with gwt-ext is that it requires ext javascript library to
>>>> run, which means that any gwt application needs to import, besides the
>>>> gwt.js file, some ext javascript files. Since the modal dialogs are
>>>> defined in the web-gwt module (so our gwt-ext dependency is there) and
>>>> we
>>>> cannot import the ext javascript files at that level, the only solution
>>>> is
>>>> to rely on the application using web-gwt to include right all required
>>>> files. It doesn't seem to me as good practice but I cannot figure out
>>>> how
>>>> big of an issue it is (since that application already has some rules to
>>>> obey, js files to include, etc to have gwt working).
>>>>
>>>> WDYT?
>>>>
>>>>
>>>>        
>> Hi,
>>
>> I think that the most important think is that updating the products
>> using gwt should be as easy as possible. The two products that
>> intensively use gwt are Watch and Curriki, and since you are a Watch
>> developer, can you try the upgrade and see how much time it takes to
>> update the failing code?
>>    
>
> I already did that with gwt-ext, the changes don't take long at all (6-8
> hours, maybe) and they can be done in a transparent manner, without
> impacting for the code that uses them, except, of course for some
> appearance changes which are inevitable. There is also some testing to be
> done to ensure that no behaviour was changed which might also take some
> time.
>
> The problem with the projects using gwt code is that we would also upgrade
> gwt to gwt 1.4 and they must handle their own dependencies and resolve any
> code failing due to API breaking changes (which are not too many,
> actually). While XWiki Watch is OK from this point of view I don't know
> anything about Curriki yet.
>
>  
>> Curriki is already on a tight deadline, so I'm
>> sure they won't like long delays (however, they are still using an older
>> branch, so they won't be affected by the trunk update yet).
>>
>> Sergiu
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>    
>
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
>  


--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs