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