22 Jun
2015
22 Jun
'15
2:46 p.m.
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, vincent(a)massol.net <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne