28 Feb
2012
28 Feb
'12
9:16 a.m.
Hi devs,
From the start Extension Manager has been designed to
be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
--
Thomas Mortagne
28 Feb
28 Feb
9:47 a.m.
Hi
On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository
By server-side module you mean the REST API ? Just for information,
what prevents it from being generic ?
(but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
Big +1
Jerome
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
10:24 a.m.
On Tue, Feb 28, 2012 at 9:47 AM, Jerome Velociter <jerome(a)winesquare.net> wrote:
--
Thomas Mortagne
Hi
On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
I just mean the xwiki-platform-extension-repository-xwiki-server-api
module which is a XWiki based implementation of the generic REST
extension protocol.
Said another way:
* generic: xwiki-platform-extension-repository-xwiki-api,
xwiki-platform-extension-repository-xwiki-handler,
xwiki-platform-extension-repository-xwiki-model
* xwiki: xwiki-platform-extension-repository-xwiki-server-api,
xwiki-platform-extension-repository-xwiki-server-ui
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository
By server-side module you mean the REST API ? Just for information,
what prevents it from being generic ? (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
Big +1
Jerome
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:25 a.m.
On Tue, Feb 28, 2012 at 10:24 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
--
Thomas Mortagne
On Tue, Feb 28, 2012 at 9:47 AM, Jerome Velociter
<jerome(a)winesquare.net> wrote:
So to be extra clear: the commons version of Extension Manager will
support installing extension coming from XWiki Repository.
Hi
On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
I just mean the xwiki-platform-extension-repository-xwiki-server-api
module which is a XWiki based implementation of the generic REST
extension protocol.
Said another way:
* generic: xwiki-platform-extension-repository-xwiki-api,
xwiki-platform-extension-repository-xwiki-handler,
xwiki-platform-extension-repository-xwiki-model
* xwiki: xwiki-platform-extension-repository-xwiki-server-api,
xwiki-platform-extension-repository-xwiki-server-ui Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository
By server-side module you mean the REST API ? Just for information,
what prevents it from being generic ? (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
Big +1
Jerome
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
29 Feb
29 Feb
2:32 a.m.
On Tue, Feb 28, 2012 at 09:16, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote;wrote:
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
Sounds good, +1
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
5:19 a.m.
+1
Thanks,
Eduard
On Wed, Feb 29, 2012 at 3:32 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Tue, Feb 28, 2012 at 09:16, Thomas Mortagne
<thomas.mortagne(a)xwiki.com
wrote:
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
Sounds good, +1
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:29 a.m.
+1
Thanks,
Marius
On Tue, Feb 28, 2012 at 10:16 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:30 a.m.
+1
Thanks
-Vincent
On Feb 28, 2012, at 9:16 AM, Thomas Mortagne wrote:
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
2 Mar
2 Mar
9:11 p.m.
On 02/28/2012 03:16 AM, Thomas Mortagne wrote:
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
Aren't there any good existing projects that handle that? I'd expect
something as common as a classloader to be fairly well developed. Do we
have any specific requirements that prevent us from using existing
libraries?
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
+1.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
3 Mar
3 Mar
11:52 a.m.
On Fri, Mar 2, 2012 at 9:11 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
--
Thomas Mortagne
On 02/28/2012 03:16 AM, Thomas Mortagne wrote:
This module is based on emory-util-classloader. Also it's not
something new written for Extension Manager it has been done for
script macro some time ago.
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
Aren't there any good existing projects that handle that? I'd expect
something as common as a classloader to be fairly well developed. Do we have
any specific requirements that prevent us from using existing libraries? = Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
+1.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5 Mar
5 Mar
12:08 p.m.
Hi guys,
I'm almost done but there is one little detail left: for easier
retro-compatibility I would like to introduce a new @Role annotation
and deprecate the @ComponentRole annotation. The idea is that Role
will "officially" take into account generic parameters while
ComponentRole does not. That way no existing component role behavior
will be broken or require crappy retro-compatibility like registering
automatically both generic and non generic roles (what I started to do
at first).
WDYT ?
Here is my +1
On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
--
Thomas Mortagne
--
Thomas Mortagne
6:52 p.m.
On Mon, Mar 5, 2012 at 12:08 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi guys,
I'm almost done but there is one little detail left: for easier
retro-compatibility I would like to introduce a new @Role annotation
and deprecate the @ComponentRole annotation. The idea is that Role
will "officially" take into account generic parameters while
ComponentRole does not. That way no existing component role behavior
will be broken or require crappy retro-compatibility like registering
automatically both generic and non generic roles (what I started to do
at first).
Wrong thread. Resending it.
WDYT ?
Here is my +1
On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
Hi devs,
From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
--
Thomas Mortagne
--
Thomas Mortagne
6:54 p.m.
On Mar 5, 2012, at 6:52 PM, Thomas Mortagne wrote:
On Mon, Mar 5, 2012 at 12:08 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
+1
Thanks
-Vincent
Hi guys,
I'm almost done but there is one little detail left: for easier
retro-compatibility I would like to introduce a new @Role annotation
and deprecate the @ComponentRole annotation. The idea is that Role
will "officially" take into account generic parameters while
ComponentRole does not. That way no existing component role behavior
will be broken or require crappy retro-compatibility like registering
automatically both generic and non generic roles (what I started to do
at first).
Wrong thread. Resending it. > WDYT ?
>
> Here is my +1
>
> On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne
> <thomas.mortagne(a)xwiki.com> wrote:
>> Hi devs,
>>
>> From the start Extension Manager has been designed to be usable
>> outside of XWiki. I would like to make this effective by moving it
>> into commons.
>>
>> Here is the detail of the operation:
>>
>> = Not moved
>>
>> * UI of Extension Manager
>> * Xar handler
>> * Server side module and UI of XWiki Repository (but the client will
>> be moved to commons since a generic REST protocol has been designed
>> for it which could be implemented by anything)
>> * Clustering module
>> * Script service module
>> * An ExecutionContextInitializer which is responsible for switching
>> the current Thread classloader for each new request with the one
>> linked to the current wiki (so that everything loading classes like
>> script macros do it from the proper classloader)
>>
>> That means that the commons version of Extension Manager will support
>> everything the current one supports except for the thing that don't
>> make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
>>
>> = Dependencies to move
>>
>> * ClassLoader module: even more than Extension Manager (and like other
>> stuff that will follow in other mails) this module is ready to be
>> moved as it is except for the attachment based support which is
>> already in a separated module and will stays in platform obviously.
>>
>> = Extracted from Extension Manager
>>
>> * Job Manager: encapsulate background task into a job providing
>> progress and status informations as well as logging isolation. In it's
>> own module.
>> * ClassLoader Manager: namespace based organization for classloaders
>> (like we have for Component Managers). In the existing classloader
>> module.
>>
>> WDYT ?
>>
>> Here is my +1
4578
days inactive
4584
days old
12 comments
7 participants
participants (7)
-
Denis Gervalle -
Eduard Moraru -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol