It seems JSR_283-810 will not be available in the near future, so we could either create our own wrapper or update to jcr 2. Creating our own wrapper would only help if we use the same maven coordinates than the original jar (javax.jcr:jcr-api), otherwise we would have to change each and every pom, might run into trouble when it comes to transitive dependencies and change back everything once there is an official version out.
So I still tend to just go with jcr 2. WDYT? Regards Carsten 2012/9/20 Ian Boston <[email protected]>: > On 20 September 2012 02:29, Felix Meschberger <[email protected]> wrote: >> Hi, >> >> Am 19.09.2012 um 09:08 schrieb Ian Boston: >> >>> On 19 September 2012 16:45, Felix Meschberger <[email protected]> wrote: >>>> Hi, >>>> >>>> I am not really a fan of this. >>>> >>>> I think the JCR spec group should come up with a fixed revision of the JCR >>>> bundle, which indicates that it really is backwards compatible >>>> (JSR_283-810) >>>> >>>> In the meantime we could do our own fix-bundling which exports both 1.x >>>> and 2.0 as proposed in the bug. >>> >>> Doe that mean the slightly stricter ranges that get applied with the >>> later bundle plugin will continue to work ie versions > 2.x < 3.0 ? >>> IIUC the patch on JSR_283-810 looks like it will export at v1.1 which >>> would cause problems for anything that was strict about its version >>> range. >> >> The export of the packages as version 2.0 was a mistake (the only excuse we >> have is, that we didn't know better at the time). >> >> My patch essentially causes the packages to be exported twice: Once with the >> seemingly correct version 1.1 and the second time with version 2.0 to not >> break bundles written against the 2.0 library. >> >> Since the classes will be the same no matter which declaration has been, >> this works perfectly (Commons IO 2.4 does a similar thing) > > > Thanks, that makes sense and covers stricter import version ranges. > Ian > >> >> Regards >> Felix >> >>> >>> Ian >>> >>>> >>>> WDYT ? >>>> >>>> On the other hand, we could just give in an update. But this is wrong >>>> somehow... >>>> >>>> Regards >>>> Felix >>>> >>>> [1] http://java.net/jira/browse/JSR_283-810 >>>> >>>> Am 18.09.2012 um 21:59 schrieb Carsten Ziegeler [email protected]: >>>> >>>>> Hi, >>>>> >>>>> I know we had this discussion here and there, however so far we don't >>>>> have a good solution and currently if bundles use jcr 1.0 as a >>>>> dependency they end up with an import of the jcr packages that just >>>>> imports 1.x - so these bundles fail in a jcr 2 environment. >>>>> This is in fact an issue with the jcr 2 bundle which should export >>>>> both versions. >>>>> >>>>> I think we really need a solution now, so either we create our own jcr >>>>> wrapper or we ramp up and require jcr 2 for all bundles. While in the >>>>> pure dependency sense, requiring version 2.0 of an api when 1.0 is >>>>> sufficient is wrong, it seems to be the most pragmatic solution we >>>>> could do today. And in practice requiring 2.0 isn't a problem. >>>>> >>>>> If no one complains or comes up with a doable alternative, I'll change >>>>> the version in the parent pom in the next days :) >>>>> >>>>> Carsten >>>>> -- >>>>> Carsten Ziegeler >>>>> [email protected] >>>> >> -- Carsten Ziegeler [email protected]
