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

Reply via email to