2012/9/24 Felix Meschberger <[email protected]>: >>> >>> 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. > > /me is confused ;-) > > Bundles are developed either against JCR 1.0 API (thus import with no > version), or against our JCR API incl. JCR 1.0 API with export (thus import > with 1.0), or against JCR 2.0 API (thus import with 2.0). This is all fine > and good and expected. > > At deployment time all these bundles want to resolve and wire. So we have to > have support for imports without a version (that's always there), with [1,2) > and with [2,3). This is where our wrapper bundle would kick in helping all > importers. > > For development time this wrapper would have no effect because the bundle > plugin would just decide on one version to import with. >
Yeah, now we're on the same page :) I got confused because you wrote "development time" in your first reply but actually meant deployment time (which I also meant by runtime...) Right, I thought we would need to create different imports, but instead we can solve it this way much easier. So let's do a wrapper :) Thanks Carsten > Regards > Felix > >> >> 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] > -- Carsten Ziegeler [email protected]
