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 <shenyua...@gmail.com>: > > 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 <piotrow...@gmail.com> 写道： > > > > 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 <shenyua...@gmail.com > > <mailto:shenyua...@gmail.com>>: > >> > >> 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 <piotrow...@gmail.com > >>> <mailto:piotrow...@gmail.com>> 写道： > >>> > >>> Sounds pretty neat and was pretty much what I was thinking of. > >>> > >>> Th >
