[xwiki-devs] [vuoe] Adding attached jar classloader in 1.1RC2
Hi, I'd like to propose to vote to add this new feature in 1.1RC2 http://jira.xwiki.org/jira/browse/XWIKI-1671 I know we should not add features, but this one would allow to run groovy script requiring libs not included in the xwiki release. For example this could allow to package the Google Docs Summer of Code project as a pure extension without configuration and even restart. It's implementatin is very safe, as nothing changes unless you add a param or a value in the context. <http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/xwiki-applications/branches> Ludovic -- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Ludovic, On Sep 5, 2007, at 1:44 AM, Ludovic Dubost wrote:
Hi,
I'd like to propose to vote to add this new feature in 1.1RC2 http://jira.xwiki.org/jira/browse/XWIKI-1671
I know we should not add features, but this one would allow to run groovy script requiring libs not included in the xwiki release. For example this could allow to package the Google Docs Summer of Code project as a pure extension without configuration and even restart.
It's implementatin is very safe, as nothing changes unless you add a param or a value in the context. <http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/xwiki- applications/branches>
I told you on chat that I was ok with this. However I'm having second doubts... Sorry :) I'd like to know more why we need to do this now. Why not commit it on trunk? It'll be in 1.2M1 in 2/3 weeks. Radu's plugin will not be integrated/cleaned up/etc before that time anyway and even then it would still work with 1.1 users, it's only a matter of installation. I don't think we should rush this. It's not so much a question of taking risks or not that doing a precedent. If we do this now, then we're breaking our RC rule and it'll happen again in the future (I think we could potentially remove betas and RCs in the future when we have 70% or more covered by automated tests but we're not there yet. So, unless there's a good reason I haven't seen, I'd rather not commit this right now on the 1.1 branch. WDYT? Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol a écrit :
Hi Ludovic,
On Sep 5, 2007, at 1:44 AM, Ludovic Dubost wrote:
Hi,
I'd like to propose to vote to add this new feature in 1.1RC2 http://jira.xwiki.org/jira/browse/XWIKI-1671
I know we should not add features, but this one would allow to run groovy script requiring libs not included in the xwiki release. For example this could allow to package the Google Docs Summer of Code project as a pure extension without configuration and even restart.
It's implementatin is very safe, as nothing changes unless you add a param or a value in the context. <http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/xwiki-applications/branches>
I told you on chat that I was ok with this. However I'm having second doubts... Sorry :)
I'd like to know more why we need to do this now. Why not commit it on trunk? It'll be in 1.2M1 in 2/3 weeks. Radu's plugin will not be integrated/cleaned up/etc before that time anyway and even then it would still work with 1.1 users, it's only a matter of installation.
I don't think we should rush this. It's not so much a question of taking risks or not that doing a precedent. If we do this now, then we're breaking our RC rule and it'll happen again in the future (I think we could potentially remove betas and RCs in the future when we have 70% or more covered by automated tests but we're not there yet.
So, unless there's a good reason I haven't seen, I'd rather not commit this right now on the 1.1 branch.
WDYT?
The actual modification to xwiki core code is 2 lines just to allow to add a class loader (without specifying a class loader the behavior is the same). Then there are a class loader (new class) and a new API to run the groovy script under that class loader. They do not impact existing API. The same code written in script is much harder (code written currently in xwiki code needs to be duplicated in groovy). Having this simple additional API in the code will allow 1.1 installations (which are going to be our stable version for a while), to be more extensible by scripting, thus allowing us to demonstrate new features (like GDocs integration for example). If we postpone that non risky change to 1.2 then we will have this feature in many many installations (our farm, our clients, in chrono, in nearbee) no earlier then beginning 2008.. since client would need to upgrade to 1.2.. Ludovic
Thanks -Vincent
-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
On Sep 5, 2007, at 11:16 AM, Ludovic Dubost wrote:
Vincent Massol a écrit :
Hi Ludovic,
On Sep 5, 2007, at 1:44 AM, Ludovic Dubost wrote:
Hi,
I'd like to propose to vote to add this new feature in 1.1RC2 http://jira.xwiki.org/jira/browse/XWIKI-1671
I know we should not add features, but this one would allow to run groovy script requiring libs not included in the xwiki release. For example this could allow to package the Google Docs Summer of Code project as a pure extension without configuration and even restart.
It's implementatin is very safe, as nothing changes unless you add a param or a value in the context. <http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/xwiki- applications/branches>
I told you on chat that I was ok with this. However I'm having second doubts... Sorry :)
I'd like to know more why we need to do this now. Why not commit it on trunk? It'll be in 1.2M1 in 2/3 weeks. Radu's plugin will not be integrated/cleaned up/etc before that time anyway and even then it would still work with 1.1 users, it's only a matter of installation.
I don't think we should rush this. It's not so much a question of taking risks or not that doing a precedent. If we do this now, then we're breaking our RC rule and it'll happen again in the future (I think we could potentially remove betas and RCs in the future when we have 70% or more covered by automated tests but we're not there yet.
So, unless there's a good reason I haven't seen, I'd rather not commit this right now on the 1.1 branch.
WDYT?
The actual modification to xwiki core code is 2 lines just to allow to add a class loader (without specifying a class loader the behavior is the same). Then there are a class loader (new class) and a new API to run the groovy script under that class loader. They do not impact existing API.
The same code written in script is much harder (code written currently in xwiki code needs to be duplicated in groovy).
Having this simple additional API in the code will allow 1.1 installations (which are going to be our stable version for a while), to be more extensible by scripting, thus allowing us to demonstrate new features (like GDocs integration for example). If we postpone that non risky change to 1.2 then we will have this feature in many many installations (our farm, our clients, in chrono, in nearbee) no earlier then beginning 2008.. since client would need to upgrade to 1.2..
Some valid points. I still think it shouldn't be committed but I'm ok we commit it since you think it's really required in 1.1. Ok everyone? Thanks -Vincent
+1 for Ludovic committing his change. Catalin On 9/5/07, Vincent Massol <[email protected]> wrote:
On Sep 5, 2007, at 11:16 AM, Ludovic Dubost wrote:
Vincent Massol a écrit :
Hi Ludovic,
On Sep 5, 2007, at 1:44 AM, Ludovic Dubost wrote:
Hi,
I'd like to propose to vote to add this new feature in 1.1RC2 http://jira.xwiki.org/jira/browse/XWIKI-1671
I know we should not add features, but this one would allow to run groovy script requiring libs not included in the xwiki release. For example this could allow to package the Google Docs Summer of Code project as a pure extension without configuration and even restart.
It's implementatin is very safe, as nothing changes unless you add a param or a value in the context. <http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/xwiki- applications/branches>
I told you on chat that I was ok with this. However I'm having second doubts... Sorry :)
I'd like to know more why we need to do this now. Why not commit it on trunk? It'll be in 1.2M1 in 2/3 weeks. Radu's plugin will not be integrated/cleaned up/etc before that time anyway and even then it would still work with 1.1 users, it's only a matter of installation.
I don't think we should rush this. It's not so much a question of taking risks or not that doing a precedent. If we do this now, then we're breaking our RC rule and it'll happen again in the future (I think we could potentially remove betas and RCs in the future when we have 70% or more covered by automated tests but we're not there yet.
So, unless there's a good reason I haven't seen, I'd rather not commit this right now on the 1.1 branch.
WDYT?
The actual modification to xwiki core code is 2 lines just to allow to add a class loader (without specifying a class loader the behavior is the same). Then there are a class loader (new class) and a new API to run the groovy script under that class loader. They do not impact existing API.
The same code written in script is much harder (code written currently in xwiki code needs to be duplicated in groovy).
Having this simple additional API in the code will allow 1.1 installations (which are going to be our stable version for a while), to be more extensible by scripting, thus allowing us to demonstrate new features (like GDocs integration for example). If we postpone that non risky change to 1.2 then we will have this feature in many many installations (our farm, our clients, in chrono, in nearbee) no earlier then beginning 2008.. since client would need to upgrade to 1.2..
Some valid points. I still think it shouldn't be committed but I'm ok we commit it since you think it's really required in 1.1.
Ok everyone?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Not that it matters, but +1 for the class loader :). Radu On 9/5/07, Catalin Hritcu <[email protected]> wrote:
+1 for Ludovic committing his change.
Catalin
On 9/5/07, Vincent Massol <[email protected]> wrote:
On Sep 5, 2007, at 11:16 AM, Ludovic Dubost wrote:
Vincent Massol a écrit :
Hi Ludovic,
On Sep 5, 2007, at 1:44 AM, Ludovic Dubost wrote:
Hi,
I'd like to propose to vote to add this new feature in 1.1RC2 http://jira.xwiki.org/jira/browse/XWIKI-1671
I know we should not add features, but this one would allow to run groovy script requiring libs not included in the xwiki release. For example this could allow to package the Google Docs Summer of Code project as a pure extension without configuration and even restart.
It's implementatin is very safe, as nothing changes unless you add a param or a value in the context. <http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/xwiki- applications/branches>
I told you on chat that I was ok with this. However I'm having second doubts... Sorry :)
I'd like to know more why we need to do this now. Why not commit it on trunk? It'll be in 1.2M1 in 2/3 weeks. Radu's plugin will not be integrated/cleaned up/etc before that time anyway and even then it would still work with 1.1 users, it's only a matter of installation.
I don't think we should rush this. It's not so much a question of taking risks or not that doing a precedent. If we do this now, then we're breaking our RC rule and it'll happen again in the future (I think we could potentially remove betas and RCs in the future when we have 70% or more covered by automated tests but we're not there yet.
So, unless there's a good reason I haven't seen, I'd rather not commit this right now on the 1.1 branch.
WDYT?
The actual modification to xwiki core code is 2 lines just to allow to add a class loader (without specifying a class loader the behavior is the same). Then there are a class loader (new class) and a new API to run the groovy script under that class loader. They do not impact existing API.
The same code written in script is much harder (code written currently in xwiki code needs to be duplicated in groovy).
Having this simple additional API in the code will allow 1.1 installations (which are going to be our stable version for a while), to be more extensible by scripting, thus allowing us to demonstrate new features (like GDocs integration for example). If we postpone that non risky change to 1.2 then we will have this feature in many many installations (our farm, our clients, in chrono, in nearbee) no earlier then beginning 2008.. since client would need to upgrade to 1.2..
Some valid points. I still think it shouldn't be committed but I'm ok we commit it since you think it's really required in 1.1.
Ok everyone?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
0 I don't understand why the need to add things in 1.1? I know some features are required for this tool, or for that client, but there will be other tools and other clients coming shortly. The problem seems to be that 1.2 will only be around in at least 3 months, and that's too late, but if we keep on delaying 1.1 just because somebody wants a new (required) feature in it, then 1.1 will be released about the time 1.2 will enter the RC period. And why would people be willing to upgrade to 1.1.1, and not to 1.2 M1? As Vincent said, this is not a required feature, as a full GData integration will only be possible in at least a month. I'd like this feature to be well tested, have a nice integration, nice UI, no bugs, good documentation, clean installation. On 9/5/07, Ludovic Dubost <[email protected]> wrote:
Hi,
I'd like to propose to vote to add this new feature in 1.1RC2 http://jira.xwiki.org/jira/browse/XWIKI-1671
I know we should not add features, but this one would allow to run groovy script requiring libs not included in the xwiki release. For example this could allow to package the Google Docs Summer of Code project as a pure extension without configuration and even restart.
It's implementatin is very safe, as nothing changes unless you add a param or a value in the context. <http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/xwiki-applications/branches> Ludovic
Sergiu -- http://purl.org/net/sergiu
participants (5)
-
Catalin Hritcu -
Ludovic Dubost -
Radu Danciu -
Sergiu Dumitriu -
Vincent Massol