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 som
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
+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
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-w
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.
>
>
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
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
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 b
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
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 se
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
th
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 t
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
13 matches
Mail list logo
