To wrap this up, I plan on closing OAK-7203 as won't fix. I agree with the idea that the code itself should work without that dependency, however the added complexity of having that reference dynamic (over system restarts, not over a single run) it simply not worth the trouble. The downside is obviously having to add another bundle to the deployment list, and the docs should of course reflect this.
thanks, alex On Tue, Feb 13, 2018 at 3:47 PM, Robert Munteanu <romb...@apache.org> wrote: > On Tue, 2018-02-13 at 15:29 +0100, Oliver Lietz wrote: > > On Tuesday 13 February 2018 14:37:29 Alex Deparvu wrote: > > > Hi, > > > > Hi, > > > > > I would not move it to oak-core, it would be (I think) a step in > > > the wrong > > > direction wrt. the modularization effort. > > > > seriously, which direction is it? oak-core now depends on oak-store- > > composite > > (which provides optional features) and oak-lucene depends on oak- > > store- > > document which is otherwise not required when running Oak with > > Segment Tar > > store. What's the point of this m12n effort? > > oak-lucene depending on oak-store-document is not a very good thing > IMO, looks wrong. But that's an implementation problem, not a design > fault in modularizing Pak. Filed [1] for it. > > The reasoning behind this is documented in OAK-6069 - Modularisation of > Oak [2], and the main driver is stop releasing all modules at a time. > For instance, a bugfix in oak-store-segment should not require > _everything_ to be released. > > [1]: https://issues.apache.org/jira/browse/OAK-7263 > [2]: https://issues.apache.org/jira/browse/OAK-6069 >
