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
