Hi, Am 25.01.2012 um 01:37 schrieb Jukka Zitting:
> Hi, > > On Wed, Jan 25, 2012 at 1:06 AM, Tobias Bocanegra <[email protected]> wrote: >> how about adding getSelectorJcrNames() and deprecate the other one? > > Yes, we can do that. It just feels silly that we have to go through > hoops like that when AFAICT were the only ones using and implementing > this interface. True, but think about downstream deployers and secondary users like Sling. But, hmm, hmm, hmm, I may have made a mistake .. updating the SPI, SPI Commons, WebDav, and JCR Commons bundles to 2.3.7 while still having had an old DavEx build embedding JCR Server 2.3.4 (or another pre-2.3.7 version). This bombed because the DavEx bundle imported spi at [2.4,3) thus precluding to operate with SPI 2.3.7 exporting spi at 3. > > And (correct me if I'm wrong), isn't the OSGi framework supposed to be > able to deal with cases where for backwards compatibility reasons more > than one version of a package needs to be present? You don't want to enter the arena of deploying the same bundle in different versions. The framework perfectly knows how to deal with this. Our software probably not ... Point is building a consistent class space where different actors use the same classes. > > I'd understand this desire better if the objection was about 1233468 > (the actual API change) rather than 1227240 (the OSGi package version > update). Is there any actual client or implementation code that gets > broken by revision 1233468 but that I didn't already update? Why then > is revision 1227240 causing trouble? The export version changed caused the problem to be flagged. Given the API change, the version change was the right thing to do such that the issue could be flagged. I tried to make this clear in my follow-up. Maybe the real problem is with the setup of the JCR Server library: we made this a bundle without any exports but with a Declarative Services descriptor for the added DavexServletService. This requires me in Sling to embed the JCR Server library to implement something slightly different on-top of the JcrRemotingServlet. Maybe we should export packages from the JCR Server library and modify the DavexServletService setup such that it is inoperable unless configuration is provided (or support configuration to disable it). This would help me in Sling to my stuff based on JcrRemotingServlet and be less bound to Jackrabbit internal dependencies. Nevertheless, I think that breaking backwards compatibility in exported packages should not have been done. Regards Felix > > BR, > > Jukka Zitting
