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. 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] >
