+1, I think it's a good way to go. Please add some description in the binary release kit to specify the difference between the weex_sdk and weex_sdk_legacy.
Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Wed, Sep 18, 2019 at 3:25 PM Jan Piotrowski <[email protected]> wrote: > > Exactly, that is the opposite of what your original email said ;) > > > weex_sdk will be compiled using the gradle-plugin mentioned above, while > > weex_sdk_legacy will not. > > But I understand now and agree with your suggestion. > > J > > Am Mi., 18. Sept. 2019 um 04:40 Uhr schrieb York Shen <[email protected]>: > > > > Nope. > > > > The class name in source code(.java) will be ‘org.apache.weex’, as this is > > the right thing to do, IMO. The apache source code release will be under > > ‘org.apache.weex’ as well. > > The weex_sdk will be built without the plugin therefore its package name > > shall also be 'org.apache.weex'. > > The weex_sdk_legacy will be built with the plugin therefore its package > > name shall be ‘com.taobao.weex'. > > Users can choose whichever the above connivence library they’d like. > > > > > > > 在 2019年9月18日，02:56，Jan Piotrowski <[email protected]> 写道： > > > > > > Sounds good. > > > > > >> weex_sdk will be compiled using the gradle-plugin mentioned above, while > > >> weex_sdk_legacy will not. > > > > > > Don't you mean the other one around? The legacy one should be built > > > using the plugin, leading to the class names being replaced with the > > > old ones. > > > > > > -J > > > > > > Am Di., 17. Sept. 2019 um 13:56 Uhr schrieb York Shen > > > <[email protected] <mailto:[email protected]>>: > > >> > > >> 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> > > >> <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 <[email protected] > > >>> <mailto:[email protected]>> 写道： > > >>> > > >>> Sounds pretty neat and was pretty much what I was thinking of. > > >>> > > >>> Th > >
