I discussed this with Hielke (Wiquery maintaner) in IRC because
wiquery google group disappeared (:-) )
and the only issue we found is the missing old constructor of
ResourceReferenceWithStringData.
I'll restore it and forward it to the new one with sane defaults and
it should be OK.

Hopefully we don't miss something else.

Do you know of some static analyzer that can check API/ABI breaks
between two .jars ?

On Tue, Oct 25, 2011 at 6:57 PM, Igor Vaynberg <[email protected]> wrote:
> if you truly broke the api (no methods with old sigs forwarding to new
> methods with some default values) and the fix is not of blocker
> priority (security, threading, etc) then this should not even be a
> question...
>
> -igor
>
> On Tue, Oct 25, 2011 at 4:11 AM, Martin Grigorov
> <[email protected]> wrote:
>> Hi,
>>
>> I've attached a patch to
>> https://issues.apache.org/jira/browse/WICKET-4161 which breaks a bit
>> the API of 
>> org.apache.wicket.resource.aggregation.ResourceReferenceAndStringData
>> which is used by
>> org.apache.wicket.resource.aggregation.AbstractResourceAggregatingHeaderResponse<R,
>> K>.
>>
>> I know that Wiquery also uses these classes in 1.5.x.
>> Can you review the change and tell me whether this improvement can be
>> added in Wicket 1.5.x or we need to wait for Wicket.next because of
>> the API break ?
>>
>> If we have resources (time, developers, ...) I think this code should
>> be either improved or dropped and replaced with a JavaScript library
>> like RequireJS/HeadJS/LABjs/...
>>
>> I have spend some time researching AMD (Asynchronous Module
>> Definition) "standard" with RequireJS as impl and I think it can solve
>> all the tasks related to resource merges, dependencies between them
>> and proper loading.
>>
>> So, the main question is: should this API break wait for Wicket.next ?
>>
>> martin-g
>>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Reply via email to