Hi, Am 24.09.2012 um 14:15 schrieb Carsten Ziegeler:
> 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...) Outch. Sorry. Regards Felix > 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]
