Hi, community Due to the restriction of Java language in method overriding [1], the solution I proposed months ago will not provide backwards-compatibility as expected but produce compiling error for users.
Therefore, I’d like to proposal a new solution to fix the problem. Package name will be renamed from 'com.taobao.weex' to 'org.apache.weex' in source code and Apache Source Release as the previous plan. Create a custom gradle-plugin which could rename package back to ‘com.taobao.weex’ at compiling time. Publish two build variants (weex_sdk and weex_sdk_legacy) each time building connivence library. weex_sdk will be compiled using the gradle-plugin mentioned above, while weex_sdk_legacy will not. Therefore, classes in weex_sdk will be under ‘org.apache.weex' package, and classes in weex_sdk_legacy will be under ‘com.taobao.weex’. New users of weex should choose weex_sdk and new API, while current users could continue using weex_sdk_legacy which provide the same API behavior as now. Finally, we would stop publishing weex_sdk_legacy sometime later. The community could benefit from the above solution in following aspects: For me, there is much less work to do in current plan than the old one. Less bug to write, less time to use. One or two weeks will be enough. For users, There is a guarantee that the API behavior of weex_sdk_legacy is the same as before because the source code after processing of gradle-plugin is the same as before. The old plan won’t give this guarantee. We make our position very clear by naming the connivence binary to weex_sdk_legacy . [1] "When overriding a method, the signatures (name and argument types) have to be the same after type erasure." Ref https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2> for detail. Best Regards, York Shen 申远 > 在 2019年7月1日，16:26，Jan Piotrowski <piotrow...@gmail.com> 写道： > > Sounds pretty neat and was pretty much what I was thinking of. > > Th
