2012/9/24 Felix Meschberger <[email protected]>: > Hi, > > Am 24.09.2012 um 13:05 schrieb Carsten Ziegeler: > >> 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. > > No. Our wrapper would only be used at development time (e.g. in the Launchpad > Builder) because the problem is actual wiring and development and setting the > dependencies.
You mean our wrapper would onle be used at runtime, right? :) For development we would need to change each module to use the wrapper. Carsten > > Regards > Felix > >> >> 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] > -- Carsten Ziegeler [email protected]
