Justin Edelson wrote
> I fixed the two failing test in JCR Installer. As mentioned last week,
> one failure (FolderDetectionTest.testMoveLibsToFoo) was caused by a
> Jackrabbit bug, for which I implemented a workaround.
Great, thanks Justin!
>
> The second failure (FolderDetectionTest.testMoveLibsToApps) was caused
> by the fact that when session.move("/src", "/dest") is called, events
> are sent only for NodeAdded /src and NodeRemoved /dest. The code in
> RootFolderListener expected to get a NodeAdded event for each node in
> the moved subtree.
>
> Looking at the JCR spec, Jackrabbit seems to be doing the right thing
> here, so I ended up removing the path checking code in r988136. The net
> result is that the watched subtrees (i.e. /apps and /libs) are scanned
> whenever any change is done inside of them. I'm certainly open to other
> alternatives for this.
Sounds good to me. I've one question :) Do we need the dependency to JCR
2 for observation of the move event? As far as I can see this is
currently the only place where jcr 2 api is used; otherwise the
jcrinstaller would still work with jcr 1. I'm not against requiring JCR
2 for the installer but if it is just for this event, we might reduce
the requirement to jcr 1
>
> In any case, all the tests are passing for me now. Created SLING-1681 to
> merge it into the reactor and SLING-1682 to add jcr and osgi install to
> launchpad.
Great
I've committed my last changes, so the stuff should be ready for a
release (there are still bugs I would like to get fixed, but as those
are there for a long time, we can release SLING-6 with them).
And I finally fixed a bug in the IT tests (the
ConfigInstallTest#testDeferredConfigInstall) - at least in my
environment there are two config admin bundles installed; as only one is
stopped, the config admin is still there, making the test fail.
I changed this to simply stop all config admins :)
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
