On Fri, Sep 23, 2011 at 1:25 PM, Vincent Massol <vincent(a)massol.net> 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.

> > 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.

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.

now. > Denis, how long should it stay there in your opinion? > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Mon, Oct 10, 2011 at 9:35 AM, Denis Gervalle <dgl(a)softec.lu> wrote: > On Fri, Oct 7, 2011 at 15:22, Thomas Mortagne <thomas.mortagne(a)xwiki.com > 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).