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