Re: [DISCUSS] Package name in Java code

[York Shen]

README file updated.

I shall update the website after next Apache Release.

Best Regards,
York Shen

申远

> 在 2019年9月24日，14:56，York Shen  写道：
> 
> I shall update the README file and website later.
> 
>> 在 2019年9月23日，17:33，Willem Jiang  写道：
>> 
>> +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  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 
>>> :
 
 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  写道：
> 
> 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 
> 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 
>>  
>> > >
>>  for detail.
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年7月1日，16:26，Jan Piotrowski >> > 写道：
>>> 
>>> Sounds pretty neat and was pretty much what I was thinking of.
>>> 
>>> Th
 
> 

Re: [DISCUSS] Package name in Java code

[York Shen]

I shall update the README file and website later.

> 在 2019年9月23日，17:33，Willem Jiang  写道：
> 
> +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  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 :
>>> 
>>> 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  写道：
 
 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 
 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 
>  
>  > 
> for detail.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年7月1日，16:26，Jan Piotrowski > > 写道：
>> 
>> Sounds pretty neat and was pretty much what I was thinking of.
>> 
>> Th
>>> 

Re: [DISCUSS] Package name in Java code

[Willem Jiang]

+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  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 :
> >
> > 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  写道：
> > >
> > > 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 
> > > 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 
> > >>  
> > >>  > >> >
> > >>  for detail.
> > >>
> > >> Best Regards,
> > >> York Shen
> > >>
> > >> 申远
> > >>
> > >>> 在 2019年7月1日，16:26，Jan Piotrowski  > >>> > 写道：
> > >>>
> > >>> Sounds pretty neat and was pretty much what I was thinking of.
> > >>>
> > >>> Th
> >

Re: [DISCUSS] Package name in Java code

[York Shen]

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 


Best Regards,
York Shen

申远

> 在 2019年9月18日，15:25，Jan Piotrowski  写道：
> 
> 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  >:
>> 
>> 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  写道：
>>> 
>>> 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 >>  >> >>:
 
 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 
  
 > 
  
 >> 
 for detail.
 
 Best Regards,
 York Shen
 
 申远
 
> 在 2019年7月1日，16:26，Jan Piotrowski    >> 写道：
> 
> Sounds pretty neat and was pretty much what I was thinking of.
> 
> Th

Re: [DISCUSS] Package name in Java code

[Jan Piotrowski]

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 :
>
> 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  写道：
> >
> > 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  > >:
> >>
> >> 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 
> >>  
> >>  >> > 
> >> for detail.
> >>
> >> Best Regards,
> >> York Shen
> >>
> >> 申远
> >>
> >>> 在 2019年7月1日，16:26，Jan Piotrowski  >>> > 写道：
> >>>
> >>> Sounds pretty neat and was pretty much what I was thinking of.
> >>>
> >>> Th
>

Re: [DISCUSS] Package name in Java code

[York Shen]

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  写道：
> 
> 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  >:
>> 
>> 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 
>>  
>> > > 
>> for detail.
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年7月1日，16:26，Jan Piotrowski >> > 写道：
>>> 
>>> Sounds pretty neat and was pretty much what I was thinking of.
>>> 
>>> Th

Re: [DISCUSS] Package name in Java code

[Jan Piotrowski]

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 :
>
> 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 
>  for 
> detail.
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年7月1日，16:26，Jan Piotrowski  写道：
> >
> > Sounds pretty neat and was pretty much what I was thinking of.
> >
> > Th
>

Re: [DISCUSS] Package name in Java code

[York Shen]

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 
 for 
detail.

Best Regards,
York Shen

申远

> 在 2019年7月1日，16:26，Jan Piotrowski  写道：
> 
> Sounds pretty neat and was pretty much what I was thinking of.
> 
> Th

Re: [DISCUSS] Package name in Java code

[Jan Piotrowski]

Sounds pretty neat and was pretty much what I was thinking of.

That users have to add the new weex_compatible package for this to
work I count as a positive, as it makes sure they are aware of the
package name change and can decide if to use the compatibility package
or rename their package usage once on their side.

I think Weex will definitely from it in the long term, so go for it!

J

Am Mo., 1. Juli 2019 um 09:34 Uhr schrieb York Shen :
>
> Thanks for your detail explanation.
>
> After some thoughts during weekend, I think though users may don’t care about 
> package names at all, we still need to give it a try for the best interest of 
> Weex unless it’s proven impossible/impractical. We failed to make things 
> right in the first year and second year, let’s make that right in the third 
> year.
>
> As for detail plan, considering there are a great deal of Java reflection 
> code currently, proxy classes may not work well and they are also bad for 
> performance. Here is what I think could solve the problem:
>
>  "copy *everything* and let it exist under two package names”, as suggested 
> by Myrle.
> Rename every package name in weex_sdk from com.alibaba.xxx to org.apache.xxx 
> and provide a stand-along package named weex_compatible, where classes still 
> are under package name of com.alibaba.xxx but inherit from org.apache.xxx. 
> All further development should be under into weex_sdk with org.apache.xxx as 
> its package name, not weex_compatible. Theoretically, existing users could 
> import weex_sdk and weex_compatible without changing code and new users 
> should just import weex_sdk. This is what I learnt after doing some research 
> on Apache dubbo this weekend [1].
>
> This refactoring may take weeks and I am not hurry to do this in next 
> release. But I think we could gain more from it than pay for it.
>
>
> [1] https://github.com/apache/dubbo/tree/master/dubbo-compatible 
> 
>
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年6月28日，18:05，Myrle Krantz  写道：
> >
> > There are cases in which packages don't get renamed upon acceptance to the
> > incubator, precisely because of the backwards compatibility question.  An
> > example of a TLP which doesn't use "apache" in its namespaces is groovy (
> > https://github.com/apache/groovy).  But it *usually* isn't a company name
> > there instead.
> >
> > Putting a company name there might make it more difficult to attract
> > contributors who don't work for alibaba.  They might believe that only
> > employees of alibaba are welcome.
> >
> > What have communicated you communicated to your current users in the past
> > about the stability of your APIs?  Jan is right that you could,
> > theoretically replace your alibaba classes with shells to redirect,.  But
> > depending on the surface area of your API, this could be a very large
> > amount of work, and the result might *still* not be completely backwards
> > compatible.  If you are going to change the package names, it is good
> > practice to at least indicate with semantic versioning or some other
> > mechanism that the new version isn't backwards compatible (you probably
> > already know that).
> >
> > One possibility is to just copy *everything* and let it exist under two
> > package names.  Then you mark the classes in the alibaba packages as
> > deprecated, and don't make future enhancements to those classes.  Users
> > will be incentivized to change to the new packages, but not forced to.  You
> > can go a few cycles like that until you believe most users have adjusted
> > their code, and then delete the alibaba classes.  Occasional backwards
> > incompatible changes made in a controlled, well-communicated manner do not
> > have to be deadly sins for every project.  You will have to decide what you
> > feel is appropriate for your project.  It *is* important that you
> > communicate to your users how you intend to handle situations like this
> > though.  People find it easier to accept things when they are not surprised.
> >
> > So, the first question is: what do you think is right for your project?
> >
> > Best Regards,
> > Myrle
> >
> > On Fri, Jun 28, 2019 at 9:58 AM Jan Piotrowski  wrote:
> >
> >> As a new user, I would probably be confused to find a
> >> `com.taobao.xxx/com.alibaba.xxx` package name in an Apache Software
> >> Foundation project.
> >>
> >> As a a developer, I have no idea how to rename a Java package in a
> >> backwards compatible way though. Proxy classes maybe that just import
> >> and "redirect" to the new packages?
> >>
> >> I don't know if there were earlier Java/Android projects added to
> >> Apache after they already had packages names in use. Might be worth
> >> asking on the incubator mailing list, maybe someone can remember
> >> something.
> >>
> >> Best,
> >> Jan
> >>
> >> Am Fr., 28. Juni 2019 um 04:45 Uhr schrieb York Shen  >>> :
> >>>
> >>> Hi, community
> >>>
> >>> As Jan pointed out[1], the Andr

Re: [DISCUSS] Package name in Java code

[York Shen]

Thanks for your detail explanation.

After some thoughts during weekend, I think though users may don’t care about 
package names at all, we still need to give it a try for the best interest of 
Weex unless it’s proven impossible/impractical. We failed to make things right 
in the first year and second year, let’s make that right in the third year.

As for detail plan, considering there are a great deal of Java reflection code 
currently, proxy classes may not work well and they are also bad for 
performance. Here is what I think could solve the problem:

 "copy *everything* and let it exist under two package names”, as suggested by 
Myrle.
Rename every package name in weex_sdk from com.alibaba.xxx to org.apache.xxx 
and provide a stand-along package named weex_compatible, where classes still 
are under package name of com.alibaba.xxx but inherit from org.apache.xxx. All 
further development should be under into weex_sdk with org.apache.xxx as its 
package name, not weex_compatible. Theoretically, existing users could import 
weex_sdk and weex_compatible without changing code and new users should just 
import weex_sdk. This is what I learnt after doing some research on Apache 
dubbo this weekend [1].

This refactoring may take weeks and I am not hurry to do this in next release. 
But I think we could gain more from it than pay for it.


[1] https://github.com/apache/dubbo/tree/master/dubbo-compatible 



Best Regards,
York Shen

申远

> 在 2019年6月28日，18:05，Myrle Krantz  写道：
> 
> There are cases in which packages don't get renamed upon acceptance to the
> incubator, precisely because of the backwards compatibility question.  An
> example of a TLP which doesn't use "apache" in its namespaces is groovy (
> https://github.com/apache/groovy).  But it *usually* isn't a company name
> there instead.
> 
> Putting a company name there might make it more difficult to attract
> contributors who don't work for alibaba.  They might believe that only
> employees of alibaba are welcome.
> 
> What have communicated you communicated to your current users in the past
> about the stability of your APIs?  Jan is right that you could,
> theoretically replace your alibaba classes with shells to redirect,.  But
> depending on the surface area of your API, this could be a very large
> amount of work, and the result might *still* not be completely backwards
> compatible.  If you are going to change the package names, it is good
> practice to at least indicate with semantic versioning or some other
> mechanism that the new version isn't backwards compatible (you probably
> already know that).
> 
> One possibility is to just copy *everything* and let it exist under two
> package names.  Then you mark the classes in the alibaba packages as
> deprecated, and don't make future enhancements to those classes.  Users
> will be incentivized to change to the new packages, but not forced to.  You
> can go a few cycles like that until you believe most users have adjusted
> their code, and then delete the alibaba classes.  Occasional backwards
> incompatible changes made in a controlled, well-communicated manner do not
> have to be deadly sins for every project.  You will have to decide what you
> feel is appropriate for your project.  It *is* important that you
> communicate to your users how you intend to handle situations like this
> though.  People find it easier to accept things when they are not surprised.
> 
> So, the first question is: what do you think is right for your project?
> 
> Best Regards,
> Myrle
> 
> On Fri, Jun 28, 2019 at 9:58 AM Jan Piotrowski  wrote:
> 
>> As a new user, I would probably be confused to find a
>> `com.taobao.xxx/com.alibaba.xxx` package name in an Apache Software
>> Foundation project.
>> 
>> As a a developer, I have no idea how to rename a Java package in a
>> backwards compatible way though. Proxy classes maybe that just import
>> and "redirect" to the new packages?
>> 
>> I don't know if there were earlier Java/Android projects added to
>> Apache after they already had packages names in use. Might be worth
>> asking on the incubator mailing list, maybe someone can remember
>> something.
>> 
>> Best,
>> Jan
>> 
>> Am Fr., 28. Juni 2019 um 04:45 Uhr schrieb York Shen >> :
>>> 
>>> Hi, community
>>> 
>>> As Jan pointed out[1], the Android package name in Weex is
>> com.taobao.xxx/com.alibaba.xxx .
>>> 
>>> I’d like to know whether there are rules about package name in ASF’s
>> project must starts with org.apache.xxx . If so, I’d like to know if there
>> is a zero-cost/low-cost upgrading method for renaming package names. It’s
>> easy to rename all Android package to org.apache.xxx , but users would
>> probably have a lot of complains about this renaming, which should cause
>> compiling error when our users are building Android App with latest Weex.
>>> 
>>> BTW: This is only for Android(Java Code), as there is no such
>> concept(Package Name) in C

Re: [DISCUSS] Package name in Java code

[Myrle Krantz]

There are cases in which packages don't get renamed upon acceptance to the
incubator, precisely because of the backwards compatibility question.  An
example of a TLP which doesn't use "apache" in its namespaces is groovy (
https://github.com/apache/groovy).  But it *usually* isn't a company name
there instead.

Putting a company name there might make it more difficult to attract
contributors who don't work for alibaba.  They might believe that only
employees of alibaba are welcome.

What have communicated you communicated to your current users in the past
about the stability of your APIs?  Jan is right that you could,
theoretically replace your alibaba classes with shells to redirect,.  But
depending on the surface area of your API, this could be a very large
amount of work, and the result might *still* not be completely backwards
compatible.  If you are going to change the package names, it is good
practice to at least indicate with semantic versioning or some other
mechanism that the new version isn't backwards compatible (you probably
already know that).

One possibility is to just copy *everything* and let it exist under two
package names.  Then you mark the classes in the alibaba packages as
deprecated, and don't make future enhancements to those classes.  Users
will be incentivized to change to the new packages, but not forced to.  You
can go a few cycles like that until you believe most users have adjusted
their code, and then delete the alibaba classes.  Occasional backwards
incompatible changes made in a controlled, well-communicated manner do not
have to be deadly sins for every project.  You will have to decide what you
feel is appropriate for your project.  It *is* important that you
communicate to your users how you intend to handle situations like this
though.  People find it easier to accept things when they are not surprised.

So, the first question is: what do you think is right for your project?

Best Regards,
Myrle

On Fri, Jun 28, 2019 at 9:58 AM Jan Piotrowski  wrote:

> As a new user, I would probably be confused to find a
> `com.taobao.xxx/com.alibaba.xxx` package name in an Apache Software
> Foundation project.
>
> As a a developer, I have no idea how to rename a Java package in a
> backwards compatible way though. Proxy classes maybe that just import
> and "redirect" to the new packages?
>
> I don't know if there were earlier Java/Android projects added to
> Apache after they already had packages names in use. Might be worth
> asking on the incubator mailing list, maybe someone can remember
> something.
>
> Best,
> Jan
>
> Am Fr., 28. Juni 2019 um 04:45 Uhr schrieb York Shen  >:
> >
> > Hi, community
> >
> > As Jan pointed out[1], the Android package name in Weex is
> com.taobao.xxx/com.alibaba.xxx .
> >
> > I’d like to know whether there are rules about package name in ASF’s
> project must starts with org.apache.xxx . If so, I’d like to know if there
> is a zero-cost/low-cost upgrading method for renaming package names. It’s
> easy to rename all Android package to org.apache.xxx , but users would
> probably have a lot of complains about this renaming, which should cause
> compiling error when our users are building Android App with latest Weex.
> >
> > BTW: This is only for Android(Java Code), as there is no such
> concept(Package Name) in C++/C/Objective C/JavaScript.
> >
> > [1] https://github.com/apache/incubator-weex/issues/2148 <
> https://github.com/apache/incubator-weex/issues/2148>
> > [2]
> https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java
> <
> https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java
> >
> >
> > Best Regards,
> > York Shen
> >
> > 申远
> >
>

Re: [DISCUSS] Package name in Java code

[Jan Piotrowski]

As a new user, I would probably be confused to find a
`com.taobao.xxx/com.alibaba.xxx` package name in an Apache Software
Foundation project.

As a a developer, I have no idea how to rename a Java package in a
backwards compatible way though. Proxy classes maybe that just import
and "redirect" to the new packages?

I don't know if there were earlier Java/Android projects added to
Apache after they already had packages names in use. Might be worth
asking on the incubator mailing list, maybe someone can remember
something.

Best,
Jan

Am Fr., 28. Juni 2019 um 04:45 Uhr schrieb York Shen :
>
> Hi, community
>
> As Jan pointed out[1], the Android package name in Weex is 
> com.taobao.xxx/com.alibaba.xxx .
>
> I’d like to know whether there are rules about package name in ASF’s project 
> must starts with org.apache.xxx . If so, I’d like to know if there is a 
> zero-cost/low-cost upgrading method for renaming package names. It’s easy to 
> rename all Android package to org.apache.xxx , but users would probably have 
> a lot of complains about this renaming, which should cause compiling error 
> when our users are building Android App with latest Weex.
>
> BTW: This is only for Android(Java Code), as there is no such concept(Package 
> Name) in C++/C/Objective C/JavaScript.
>
> [1] https://github.com/apache/incubator-weex/issues/2148 
> 
> [2] 
> https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java
>  
> 
>
> Best Regards,
> York Shen
>
> 申远
>