[xwiki-devs] [PROPOSAL] Move Extension Manager to commons
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
Hi On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
On Tue, Feb 28, 2012 at 9:47 AM, Jerome Velociter <[email protected]> wrote:
Hi
On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne <[email protected]> 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 ?
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
(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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Tue, Feb 28, 2012 at 10:24 AM, Thomas Mortagne <[email protected]> wrote:
On Tue, Feb 28, 2012 at 9:47 AM, Jerome Velociter <[email protected]> wrote:
Hi
On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne <[email protected]> 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 ?
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
So to be extra clear: the commons version of Extension Manager will support installing extension coming from 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
Big +1
Jerome
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
On Tue, Feb 28, 2012 at 09:16, Thomas Mortagne <[email protected]>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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
+1 Thanks, Eduard On Wed, Feb 29, 2012 at 3:32 AM, Denis Gervalle <[email protected]> wrote:
On Tue, Feb 28, 2012 at 09:16, Thomas Mortagne <[email protected]
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Marius On Tue, Feb 28, 2012 at 10:16 AM, Thomas Mortagne <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+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
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/
On Fri, Mar 2, 2012 at 9:11 PM, Sergiu Dumitriu <[email protected]> wrote:
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?
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.
= 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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 <[email protected]> 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
On Mon, Mar 5, 2012 at 12:08 PM, Thomas Mortagne <[email protected]> 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 <[email protected]> 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
-- Thomas Mortagne
On Mar 5, 2012, at 6:52 PM, Thomas Mortagne wrote:
On Mon, Mar 5, 2012 at 12:08 PM, Thomas Mortagne <[email protected]> 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.
+1 Thanks -Vincent
WDYT ?
Here is my +1
On Tue, Feb 28, 2012 at 9:16 AM, Thomas Mortagne <[email protected]> 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
participants (7)
-
Denis Gervalle -
Eduard Moraru -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol