[xwiki-devs] [PROPOSAL] Move oldcore query plugin to legacy
Hi dev, The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query. So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it Note planning to do it in 3.2, that's for 3.3M1. WDYT ? +1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE -- Thomas Mortagne
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code. Thanks -Vincent
On Fri, Sep 23, 2011 at 13:25, Vincent Massol <[email protected]> wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
+1, we still use it on some old project.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On 09/23/2011 08:19 AM, Denis Gervalle wrote:
On Fri, Sep 23, 2011 at 13:25, Vincent Massol<[email protected]> wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
+1, we still use it on some old project.
Then it should be moved to legacy in 3.2M3 -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]> wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]> wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion? Thanks -Vincent
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now. Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form. Note that from what I understood from a conversation we had with Denis it's not working very well. So what do we do after all ? 1) nothing 2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ? 3) move to retired WDYT ? I'm now -1 for 3) since it's impossible to move method to retired. I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK. On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol <[email protected]> wrote:
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]> wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 10/07/2011 09:22 AM, Thomas Mortagne wrote:
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now.
Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form.
Note that from what I understood from a conversation we had with Denis it's not working very well.
So what do we do after all ?
1) nothing 2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ? 3) move to retired
WDYT ?
I'm now -1 for 3) since it's impossible to move method to retired.
I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK.
Indeed, those methods haven't been used in a while. Ludovic should know where (if) they're used. I also vote for 2. The displaySearch methods should be fixed later.
On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol<[email protected]> wrote:
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol<[email protected]> wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion?
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Fri, Oct 7, 2011 at 4:22 PM, Thomas Mortagne <[email protected]> wrote:
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now.
Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form.
Note that from what I understood from a conversation we had with Denis it's not working very well.
So what do we do after all ?
1) nothing
2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ?
I'm not sure what those methods do, so I don't think Application Within minutes will provide an alternative (at least not in the first version, which needs to work on 3.2). I'm +0 for 2). Thanks, Marius
3) move to retired
WDYT ?
I'm now -1 for 3) since it's impossible to move method to retired.
I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK.
On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol <[email protected]> wrote:
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]> wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Oct 10, 2011 at 9:19 AM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Oct 7, 2011 at 4:22 PM, Thomas Mortagne <[email protected]> wrote:
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now.
Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form.
Note that from what I understood from a conversation we had with Denis it's not working very well.
So what do we do after all ?
1) nothing
2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ?
I'm not sure what those methods do, so I don't think Application Within minutes will provide an alternative (at least not in the first version, which needs to work on 3.2). I'm +0 for 2).
By alternative I was talking about the general idea of making easy to create a search form for any object.
Thanks, Marius
3) move to retired
WDYT ?
I'm now -1 for 3) since it's impossible to move method to retired.
I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK.
On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol <[email protected]> wrote:
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]> wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Fri, Oct 7, 2011 at 15:22, Thomas Mortagne <[email protected]>wrote:
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now.
Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form.
Note that from what I understood from a conversation we had with Denis it's not working very well.
I should confirm that, I would have said that it is not working at all if you want to do anything more than very basic search with simple text field. There is issue with list, multi-select, boolean, etc... We have used it after some patches, part of them were commited to master, but not all. So I doubt there is any user of these functions that also intend to migrate to the latest version.
So what do we do after all ?
1) nothing 2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ? 3) move to retired
WDYT ?
I'm now -1 for 3) since it's impossible to move method to retired.
From what I know of it, and +1 for 2) and even +1 for 3) if it is less work. We use it on 2.4 currently, but if I have to upgrade any site using it to 3.x, I will probably rewrite the search part anyway. I know we do not have an alternative, but it is a function that is not really used anyway due to its caveat. So this is not an issue to retire it now. Of course, we should think about providing similar search feature in the future.
Denis
I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK.
On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol <[email protected]> wrote:
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]>
wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mon, Oct 10, 2011 at 9:35 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Oct 7, 2011 at 15:22, Thomas Mortagne <[email protected]>wrote:
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now.
Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form.
Note that from what I understood from a conversation we had with Denis it's not working very well.
I should confirm that, I would have said that it is not working at all if you want to do anything more than very basic search with simple text field. There is issue with list, multi-select, boolean, etc... We have used it after some patches, part of them were commited to master, but not all. So I doubt there is any user of these functions that also intend to migrate to the latest version.
So what do we do after all ?
1) nothing 2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ? 3) move to retired
WDYT ?
I'm now -1 for 3) since it's impossible to move method to retired.
From what I know of it, and +1 for 2) and even +1 for 3) if it is less work. We use it on 2.4 currently, but if I have to upgrade any site using it to 3.x, I will probably rewrite the search part anyway. I know we do not have an alternative, but it is a function that is not really used anyway due to its caveat. So this is not an issue to retire it now. Of course, we should think about providing similar search feature in the future.
I'm not really against the idea of retire it but I have no idea how to retire methods so it's either move them to legacy with aspects or delete them (which would be a lot easier than putting that in aspect since right now I have no idea how to put interface method in an aspect, need to look at AspectJ doc).
Denis
I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK.
On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol <[email protected]> wrote:
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]>
wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- 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
-- Thomas Mortagne
On Mon, Oct 10, 2011 at 09:49, Thomas Mortagne <[email protected]>wrote:
On Mon, Oct 10, 2011 at 9:35 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Oct 7, 2011 at 15:22, Thomas Mortagne <[email protected] wrote:
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now.
Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form.
Note that from what I understood from a conversation we had with Denis it's not working very well.
I should confirm that, I would have said that it is not working at all if you want to do anything more than very basic search with simple text field. There is issue with list, multi-select, boolean, etc... We have used it after some patches, part of them were commited to master, but not all. So I doubt there is any user of these functions that also intend to migrate to the latest version.
So what do we do after all ?
1) nothing 2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ? 3) move to retired
WDYT ?
I'm now -1 for 3) since it's impossible to move method to retired.
From what I know of it, and +1 for 2) and even +1 for 3) if it is less work. We use it on 2.4 currently, but if I have to upgrade any site using it to 3.x, I will probably rewrite the search part anyway. I know we do not have an alternative, but it is a function that is not really used anyway due to its caveat. So this is not an issue to retire it now. Of course, we should think about providing similar search feature in the future.
I'm not really against the idea of retire it but I have no idea how to retire methods so it's either move them to legacy with aspects or delete them (which would be a lot easier than putting that in aspect since right now I have no idea how to put interface method in an aspect, need to look at AspectJ doc).
This what 3) means to me, move the plugin to retire, and delete the method. I am almost sure that building the aspect will be useless, so if this is long and difficult leave it. (I have never converted existing code in aspect, so I do not know well the hard work it could be)
From what you say, +1 for 3).
Denis
Denis
I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK.
On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol <[email protected]> wrote:
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]>
wrote:
On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote:
> Hi dev, > > The new query manager component work pretty well and starts to be
used
> more and more so I think we should remove com.xpn.xwiki.plugin.query. > > So here is the proposals: > (1) move it to legacy > (2) move it to retired is it's own maven project so that it's easy to > build and produce a jar if someone wants to use it > > Note planning to do it in 3.2, that's for 3.3M1. > > WDYT ? > > +1 for (2): it's the last thing that trigger dependency on jackrabbit > so even if we get rid of jackrabbit in oldcore by moving it to > legacy-oldcore it would still be in XE
I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- 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
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mon, Oct 10, 2011 at 10:18 AM, Denis Gervalle <[email protected]> wrote:
On Mon, Oct 10, 2011 at 09:49, Thomas Mortagne <[email protected]>wrote:
On Mon, Oct 10, 2011 at 9:35 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Oct 7, 2011 at 15:22, Thomas Mortagne <[email protected] wrote:
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now.
Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form.
Note that from what I understood from a conversation we had with Denis it's not working very well.
I should confirm that, I would have said that it is not working at all if you want to do anything more than very basic search with simple text field. There is issue with list, multi-select, boolean, etc... We have used it after some patches, part of them were commited to master, but not all. So I doubt there is any user of these functions that also intend to migrate to the latest version.
So what do we do after all ?
1) nothing 2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ? 3) move to retired
WDYT ?
I'm now -1 for 3) since it's impossible to move method to retired.
From what I know of it, and +1 for 2) and even +1 for 3) if it is less work. We use it on 2.4 currently, but if I have to upgrade any site using it to 3.x, I will probably rewrite the search part anyway. I know we do not have an alternative, but it is a function that is not really used anyway due to its caveat. So this is not an issue to retire it now. Of course, we should think about providing similar search feature in the future.
I'm not really against the idea of retire it but I have no idea how to retire methods so it's either move them to legacy with aspects or delete them (which would be a lot easier than putting that in aspect since right now I have no idea how to put interface method in an aspect, need to look at AspectJ doc).
This what 3) means to me, move the plugin to retire, and delete the method. I am almost sure that building the aspect will be useless, so if this is long and difficult leave it. (I have never converted existing code in aspect, so I do not know well the hard work it could be) From what you say, +1 for 3).
Anyone else thinking like this ? I would certainly be happy to to having to find a way to put all that in aspects...
Denis
Denis
I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK.
On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol <[email protected]> wrote:
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]>
wrote:
> > On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote: > >> Hi dev, >> >> The new query manager component work pretty well and starts to be
used
>> more and more so I think we should remove com.xpn.xwiki.plugin.query. >> >> So here is the proposals: >> (1) move it to legacy >> (2) move it to retired is it's own maven project so that it's easy to >> build and produce a jar if someone wants to use it >> >> Note planning to do it in 3.2, that's for 3.3M1. >> >> WDYT ? >> >> +1 for (2): it's the last thing that trigger dependency on jackrabbit >> so even if we get rid of jackrabbit in oldcore by moving it to >> legacy-oldcore it would still be in XE > > I'd say (1) then (2) since it could be used by some external code.
It's the same for any other things we retired. The question is more do we still want to maintain it (legacy) or not (retired), in both case anyone can still use it if he really wants either by using the 3.2 version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- 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
-- 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
-- Thomas Mortagne
On Oct 10, 2011, at 11:08 AM, Thomas Mortagne wrote:
On Mon, Oct 10, 2011 at 10:18 AM, Denis Gervalle <[email protected]> wrote:
On Mon, Oct 10, 2011 at 09:49, Thomas Mortagne <[email protected]>wrote:
On Mon, Oct 10, 2011 at 9:35 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Oct 7, 2011 at 15:22, Thomas Mortagne <[email protected] wrote:
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now.
Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form.
Note that from what I understood from a conversation we had with Denis it's not working very well.
I should confirm that, I would have said that it is not working at all if you want to do anything more than very basic search with simple text field. There is issue with list, multi-select, boolean, etc... We have used it after some patches, part of them were commited to master, but not all. So I doubt there is any user of these functions that also intend to migrate to the latest version.
So what do we do after all ?
1) nothing 2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ? 3) move to retired
WDYT ?
I'm now -1 for 3) since it's impossible to move method to retired.
From what I know of it, and +1 for 2) and even +1 for 3) if it is less work. We use it on 2.4 currently, but if I have to upgrade any site using it to 3.x, I will probably rewrite the search part anyway. I know we do not have an alternative, but it is a function that is not really used anyway due to its caveat. So this is not an issue to retire it now. Of course, we should think about providing similar search feature in the future.
I'm not really against the idea of retire it but I have no idea how to retire methods so it's either move them to legacy with aspects or delete them (which would be a lot easier than putting that in aspect since right now I have no idea how to put interface method in an aspect, need to look at AspectJ doc).
This what 3) means to me, move the plugin to retire, and delete the method. I am almost sure that building the aspect will be useless, so if this is long and difficult leave it. (I have never converted existing code in aspect, so I do not know well the hard work it could be) From what you say, +1 for 3).
Anyone else thinking like this ? I would certainly be happy to to having to find a way to put all that in aspects…
+1 for 2) ie move to legacy. The reason I say this is because I don't know if it's used or not in the wild so I prefer to take the careful route and 1) deprecate the methods, 2) move to legacy for a few releases and 3) then completely remove in, say, 4.0M1. If Ludovic tells us he doesn't remember it to be used anywhere then I'd be +1 for 3). Thanks -Vincent
Denis
Denis
I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK.
On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol <[email protected]> wrote:
On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote:
> On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]>
wrote:
>> >> On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote: >> >>> Hi dev, >>> >>> The new query manager component work pretty well and starts to be
used
>>> more and more so I think we should remove com.xpn.xwiki.plugin.query. >>> >>> So here is the proposals: >>> (1) move it to legacy >>> (2) move it to retired is it's own maven project so that it's easy to >>> build and produce a jar if someone wants to use it >>> >>> Note planning to do it in 3.2, that's for 3.3M1. >>> >>> WDYT ? >>> >>> +1 for (2): it's the last thing that trigger dependency on jackrabbit >>> so even if we get rid of jackrabbit in oldcore by moving it to >>> legacy-oldcore it would still be in XE >> >> I'd say (1) then (2) since it could be used by some external code. > > It's the same for any other things we retired. The question is more do > we still want to maintain it (legacy) or not (retired), in both case > anyone can still use it if he really wants either by using the 3.2 > version or building the retired one.
Denis said he was still using it so I'd say yes to put it in legacy for now. Denis, how long should it stay there in your opinion?
Thanks -Vincent
On Tue, Oct 11, 2011 at 11:45 AM, Vincent Massol <[email protected]> wrote:
On Oct 10, 2011, at 11:08 AM, Thomas Mortagne wrote:
On Mon, Oct 10, 2011 at 10:18 AM, Denis Gervalle <[email protected]> wrote:
On Mon, Oct 10, 2011 at 09:49, Thomas Mortagne <[email protected]>wrote:
On Mon, Oct 10, 2011 at 9:35 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Oct 7, 2011 at 15:22, Thomas Mortagne <[email protected] wrote:
Just seen that we have a bunch of display related method based on Query plugin for which we don't have any alternative to propose right now.
Basically it's supposed to allow to easily display a search form for any field the same way you can display a edit form.
Note that from what I understood from a conversation we had with Denis it's not working very well.
I should confirm that, I would have said that it is not working at all if you want to do anything more than very basic search with simple text field. There is issue with list, multi-select, boolean, etc... We have used it after some patches, part of them were commited to master, but not all. So I doubt there is any user of these functions that also intend to migrate to the latest version.
So what do we do after all ?
1) nothing 2) still deprecate and move to legacy, is app within minutes supposed to provide an alternative ? 3) move to retired
WDYT ?
I'm now -1 for 3) since it's impossible to move method to retired.
From what I know of it, and +1 for 2) and even +1 for 3) if it is less work. We use it on 2.4 currently, but if I have to upgrade any site using it to 3.x, I will probably rewrite the search part anyway. I know we do not have an alternative, but it is a function that is not really used anyway due to its caveat. So this is not an issue to retire it now. Of course, we should think about providing similar search feature in the future.
I'm not really against the idea of retire it but I have no idea how to retire methods so it's either move them to legacy with aspects or delete them (which would be a lot easier than putting that in aspect since right now I have no idea how to put interface method in an aspect, need to look at AspectJ doc).
This what 3) means to me, move the plugin to retire, and delete the method. I am almost sure that building the aspect will be useless, so if this is long and difficult leave it. (I have never converted existing code in aspect, so I do not know well the hard work it could be) From what you say, +1 for 3).
Anyone else thinking like this ? I would certainly be happy to to having to find a way to put all that in aspects…
+1 for 2) ie move to legacy. The reason I say this is because I don't know if it's used or not in the wild so I prefer to take the careful route and 1) deprecate the methods, 2) move to legacy for a few releases and 3) then completely remove in, say, 4.0M1.
Ok lets move it to legacy for now, I have it ready to be merged anyway.
If Ludovic tells us he doesn't remember it to be used anywhere then I'd be +1 for 3).
Thanks -Vincent
Denis
Denis
I would says lets still deprecate and move it to legacy even if we don't provide right now an exact alternative, it's not like it was making impossible to search something since we don't use this at all in XE/XEM since a very long time AFAIK.
On Fri, Sep 30, 2011 at 11:10 AM, Vincent Massol <[email protected]> wrote: > > On Sep 30, 2011, at 9:06 AM, Thomas Mortagne wrote: > >> On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <[email protected]> wrote: >>> >>> On Sep 23, 2011, at 1:08 PM, Thomas Mortagne wrote: >>> >>>> Hi dev, >>>> >>>> The new query manager component work pretty well and starts to be
used
>>>> more and more so I think we should remove com.xpn.xwiki.plugin.query. >>>> >>>> So here is the proposals: >>>> (1) move it to legacy >>>> (2) move it to retired is it's own maven project so that it's easy to >>>> build and produce a jar if someone wants to use it >>>> >>>> Note planning to do it in 3.2, that's for 3.3M1. >>>> >>>> WDYT ? >>>> >>>> +1 for (2): it's the last thing that trigger dependency on jackrabbit >>>> so even if we get rid of jackrabbit in oldcore by moving it to >>>> legacy-oldcore it would still be in XE >>> >>> I'd say (1) then (2) since it could be used by some external code. >> >> It's the same for any other things we retired. The question is more do >> we still want to maintain it (legacy) or not (retired), in both case >> anyone can still use it if he really wants either by using the 3.2 >> version or building the retired one. > > Denis said he was still using it so I'd say yes to put it in legacy for now. > Denis, how long should it stay there in your opinion? > > Thanks > -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 09/23/2011 07:08 AM, Thomas Mortagne wrote:
Hi dev,
The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE
+1 for (2) as well. -- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (5)
-
Denis Gervalle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol