I perfectly understand the goal but I find this a bit extreme. Thing is that if we were having nested spaces support from the start this constructor would have probably been a logical helper anyway.
I agree that right now tracking use of this constructor often find things to fix (note that most of the time the fix is clearly not to use the one taking a list of spaces instead, it usually lead to a refactoring of the calling method) and I did found lots of stuff by doing it. There is also plenty of perfectly valid use cases where having to use Arrays.asList is a bit of a pain like classes (but most of those are more about LocalDocumentReference#LocalDocumentReference(String spaceName, String pageName) constructor than DocumentReference one). On Mon, Jun 22, 2015 at 1:54 PM, [email protected] <[email protected]> wrote: > Hi devs, > > Following http://markmail.org/message/sfqing2nnvk2lhqg I’d like to propose > that starting on the 29 we do the following: > > * Move the DocumentReference constructors and Script Services accepting a > single space to legacy (using Aspects) > * Update RN for 7.2M1 to indicate that extensions depending on 7.2M1+ need to > either update their code or depend on the legacy modules > * All work together to fix the build which will be broken to fix the 1500 > occurrences or so (a lot of them are tests) > * At the same time update the tests to always test using more than 1 space > since testing for 2 spaces will make sure the code supports nested spaces > (this is not true when testing with a single space). > * Whenever it’s too difficult to fix the code right away to support NS, pass > a single space (but using the "List<String> spaces” constructor signature) > BUT create a JIRA issue to remember to fix the issue. > > The idea is that there will be build chaos for the week of the 29th but that > we take the week to stabilize the build, all together. > > I believe this would help us get faster to supporting NS. > > WDYT? Too bold or ok? :) > > 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
