For now I have inlined the ImmutableTree within oak-lucene and have opened OAK-2270 to ensure that this workaround gets fixed before the release. This would allow the osgi testcases to pass.
@Michael - In the meanwhile we can discuss the possible approach for this problem Chetan Mehrotra On Fri, Nov 14, 2014 at 5:28 PM, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: > On Fri, Nov 14, 2014 at 5:10 PM, Michael Dürig <mdue...@apache.org> wrote: >> I was thinking of introducing some sort of a factory for Tree instances and >> export that API. That way we wouldn't have to come up with our one tree >> implementations in all places where we need it but still leave the >> underlying Tree implementation unspecified thus enabling them to evolve. > > That would be good. For this case I tried to have my own Tree like > implementation. Most of the logic works fine but then got stuck with > ReadOnlyTypeManager as that only works with real Tree! So I need to > construct a tree from NodeState at mimimum. > > If i go the route of TreeFactory then one place I get stuck is support > for assembling a tree with individual NodeState i.e. replacement for > > public ImmutableTree(@Nonnull ImmutableTree parent, @Nonnull String > name, @Nonnull NodeState state) > > May be if we have support for "friends" in OSGi so as to allow > oak-lucene access to internal classes as special case then usage of > oak-core classes in oak-lucene would be at par with other classes in > oak-core and oak-lucene would not be discriminated :( > > So stuck here now for proper solution. Any pointers! > > Chetan Mehrotra
