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 <shenyua...@gmail.com>: > > 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 > <https://github.com/apache/dubbo/tree/master/dubbo-compatible> > > > Best Regards, > York Shen > > 申远 > > > 在 2019年6月28日，18:05，Myrle Krantz <my...@apache.org> 写道： > > > > 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 <piotrow...@gmail.com> 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 <shenyua...@gmail.com > >>> : > >>> > >>> 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 > >>> > >>> 申远 > >>> > >> >
