You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@weex.apache.org by York Shen <sh...@gmail.com> on 2019/09/17 11:56:22 UTC
Re: [DISCUSS] Package name in Java code
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 <pi...@gmail.com> 写道：
>
> Sounds pretty neat and was pretty much what I was thinking of.
>
> Th
Re: [DISCUSS] Package name in Java code
Posted by York Shen <sh...@gmail.com>.
Finally, every Java source code is under org.apache.weex [1].
I shall rewrite script related to publishing connivence binary later to enable legacy connivence binary, but that’s another story. For Apache release part, we are good after the PR is merged.
[1] https://github.com/apache/incubator-weex/pull/2885 <https://github.com/apache/incubator-weex/pull/2885>
Best Regards,
York Shen
申远
> 在 2019年9月18日，15:25，Jan Piotrowski <pi...@gmail.com> 写道：
>
> 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 <shenyuancs@gmail.com <ma...@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 <pi...@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 <shenyuancs@gmail.com <ma...@gmail.com> <mailto:shenyuancs@gmail.com <ma...@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>> <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 <piotrowski@gmail.com <ma...@gmail.com> <mailto:piotrowski@gmail.com <ma...@gmail.com>>> 写道：
>>>>>
>>>>> Sounds pretty neat and was pretty much what I was thinking of.
>>>>>
>>>>> Th
Re: [DISCUSS] Package name in Java code
Posted by York Shen <sh...@gmail.com>.
README file updated.
I shall update the website after next Apache Release.
Best Regards,
York Shen
申远
> 在 2019年9月24日，14:56，York Shen <sh...@gmail.com> 写道：
>
> I shall update the README file and website later.
>
>> 在 2019年9月23日，17:33，Willem Jiang <wi...@gmail.com> 写道：
>>
>> +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 <pi...@gmail.com> 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 <sh...@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 <pi...@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 <shenyuancs@gmail.com <ma...@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 <piotrowski@gmail.com <ma...@gmail.com>> 写道：
>>>>>>>
>>>>>>> Sounds pretty neat and was pretty much what I was thinking of.
>>>>>>>
>>>>>>> Th
>>>>
>
Re: [DISCUSS] Package name in Java code
Posted by York Shen <sh...@gmail.com>.
I shall update the README file and website later.
> 在 2019年9月23日，17:33，Willem Jiang <wi...@gmail.com> 写道：
>
> +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 <pi...@gmail.com> 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 <sh...@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 <pi...@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 <shenyuancs@gmail.com <ma...@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 <piotrowski@gmail.com <ma...@gmail.com>> 写道：
>>>>>>
>>>>>> Sounds pretty neat and was pretty much what I was thinking of.
>>>>>>
>>>>>> Th
>>>
Re: [DISCUSS] Package name in Java code
Posted by Willem Jiang <wi...@gmail.com>.
+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 <pi...@gmail.com> 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 <sh...@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 <pi...@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 <shenyuancs@gmail.com <ma...@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 <piotrowski@gmail.com <ma...@gmail.com>> 写道：
> > >>>
> > >>> Sounds pretty neat and was pretty much what I was thinking of.
> > >>>
> > >>> Th
> >
Re: [DISCUSS] Package name in Java code
Posted by Jan Piotrowski <pi...@gmail.com>.
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 <sh...@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 <pi...@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 <shenyuancs@gmail.com <ma...@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 <piotrowski@gmail.com <ma...@gmail.com>> 写道：
> >>>
> >>> Sounds pretty neat and was pretty much what I was thinking of.
> >>>
> >>> Th
>
Re: [DISCUSS] Package name in Java code
Posted by York Shen <sh...@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 <pi...@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 <shenyuancs@gmail.com <ma...@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 <piotrowski@gmail.com <ma...@gmail.com>> 写道：
>>>
>>> Sounds pretty neat and was pretty much what I was thinking of.
>>>
>>> Th
Re: [DISCUSS] Package name in Java code
Posted by Jan Piotrowski <pi...@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 <sh...@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> for detail.
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年7月1日，16:26，Jan Piotrowski <pi...@gmail.com> 写道：
> >
> > Sounds pretty neat and was pretty much what I was thinking of.
> >
> > Th
>