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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
