dubbo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: About the parent pom, groupId and package name of Dubbo project
Date Mon, 19 Mar 2018 11:56:22 GMT
We don't expect the rename of all packages to happen overnight, or in the
first release.  It should be expected by the time you graduate from
incubation that the rename is complete, or at least there's an
understanding of how it's going to happen.  I would say that considering
its using a company name the rename would block graduation.  Changing group
IDs should be simple as a first step.  What I would recommend:

- Plan for a Dubbo 3.0 that does the full rename.
- Any APIs a user may program against, leave as com.alibaba.dubbo, anything
internal start to rename to org.apache.dubbo.
- Anything new added should be named as org.apache.dubbo instead of
com.alibaba.dubbo.  This should start with the next release cycle.
- One approach, a strangler pattern, would be to start to create duplicates
of each class in the org.apache.dubbo scheme, and have the existing
com.alibaba.dubbo classes extend those.

Happy to talk through more ideas, these are mostly shots in the dark that I
have seen work in other projects to some success.

John

On Mon, Mar 19, 2018 at 7:29 AM shang zonghai <yiji.github@hotmail.com>
wrote:

>
>
>
> 2. Shall we need to change all the java package name to org.apache.* ? If
> do this, users will encounter the upgrading problem.
>
>
> The current package is com.alibaba.dubbo right?  Unfortunately this puts us
> into a "you have to rename it" situation.  Including the company name in
> the package is a problem for our branding/trademarks.
>
>
> 3. Now, our groupId is "com.alibaba", shall we need to change it to
> "org.apache"?
>
>
> Most projects follow a "org.apache.projectName" naming scheme.  So
> org.apache.dubbo would be expected.
>
>
>
> Considering that a large number of users already use dubbo,Changing the
> name of the package can lead to breaking the compatibility.
>
> for case 1:  New users use dubbo, we should do nothing.
>
>
> case 2:     The user is convenient to upgrade dubbo to apache version(
> change com.alibaba.xxx to com.apache.xx),  consumer and server upgrades at
> the same time.
>
> We can provide tools to automatically convert the package name, the name
> of the extension interceptor, the package name of the xml configuration,
> etc.
>
> case 3:   The user is convenient to upgrade dubbo to apache version(
> change com.alibaba.xxx to com.apache.xx),  consumer and server can't
> upgrades at the same time.
>
> This scenario is the most complicated, we should be compatible at the
> source code level,and prompting future versions will remove the compatible
> code. It is recommended that you use this tool to manually convert old code.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message