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 Tue, 20 Mar 2018 02:10:05 GMT
On Mon, Mar 19, 2018 at 9:13 PM jun liu <ken.lj.hz@gmail.com> wrote:

> > - Plan for a Dubbo 3.0 that does the full rename.
>
> 3.0 is on progress,  can be a milestone fully rename package.
>
> > - 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.
>
> These two steps i think we can start from 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.
>
> This part i don’t fully understand: will the  org.apache.dubbo duplicates
> make any differences when we remove the com.alibaba.dubbo ones?
>
>
Let's say you take CacheFilter as an example (just grabbed it at random
more or less)
https://github.com/apache/incubator-dubbo/blob/master/dubbo-filter/dubbo-filter-cache/src/main/java/com/alibaba/dubbo/cache/filter/CacheFilter.java

1. Create a class org.apache.dubbo.cache.filter.CacheFilter
2. Copy existing contents into it
3. Have com.alibaba.dubbo.cache.filter.CacheFilter extend the o.a.d version
and mark it as @Deprecated.  This keeps API compatibility in place, and
encourages users to switch out.


>
> > On 19 Mar 2018, at 7:56 PM, John D. Ament <johndament@apache.org> wrote:
> >
> > 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