You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by Yong Zhu <di...@gmail.com> on 2018/03/16 07:47:35 UTC
About the parent pom, groupId and package name of Dubbo project
Hi, all
I'm working on this issue:
https://issues.apache.org/jira/projects/DUBBO/issues/DUBBO-7?filter=allopenissues
I have the below questions:
1. Shall we need to change the pom.xml parent to org.apache:apache:19 ? Now
we use sonatype oss as the central repository.
2. Shall we need to change all the java package name to org.apache.* ? If
do this, users will encounter the upgrading problem.
3. Now, our groupId is "com.alibaba", shall we need to change it to
"org.apache"?
Thanks.
Yong Zhu.
Re: About the parent pom, groupId and package name of Dubbo project
Posted by shang zonghai <yi...@hotmail.com>.
Thank you very much for your valuable advice.
What we are worried about is whether or not it will affect the graduation from apache incubation.
在 2018年3月20日，10:41，John D. Ament <jo...@apache.org>> 写道：
On Mon, Mar 19, 2018 at 10:32 PM Yong Zhu <di...@gmail.com>> wrote:
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.
-------
Does the compatible code need to be deleted before graduating or always
exist?
I would imagine a compatibility layer gets deleted when not needed any longer
Re: About the parent pom, groupId and package name of Dubbo project
Posted by shang zonghai <yi...@hotmail.com>.
>> 3. In quick start section, the com.alibaba.* group id in still in use,
>> is it possible to keep it until next release?
>
> I would be OK with that as long as the long term plan is removed prior to graduation.
I expect to be able to take this part of the job, hope to contribute to the apache/dubbo community.
yiji
Re: About the parent pom, groupId and package name of Dubbo project
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Mar 19, 2018 at 10:32 PM Yong Zhu <di...@gmail.com> wrote:
> 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.
> -------
> Does the compatible code need to be deleted before graduating or always
> exist?
>
>
I would imagine a compatibility layer gets deleted when not needed any
longer.
> 2018-03-20 10:10 GMT+08:00 John D. Ament <jo...@apache.org>:
>
> > On Mon, Mar 19, 2018 at 9:13 PM jun liu <ke...@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 <jo...@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.
> > > >>
> > > >>
> > >
> > >
> >
>
Re: About the parent pom, groupId and package name of Dubbo project
Posted by Yong Zhu <di...@gmail.com>.
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.
-------
Does the compatible code need to be deleted before graduating or always
exist?
2018-03-20 10:10 GMT+08:00 John D. Ament <jo...@apache.org>:
> On Mon, Mar 19, 2018 at 9:13 PM jun liu <ke...@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 <jo...@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.
> > >>
> > >>
> >
> >
>
Re: About the parent pom, groupId and package name of Dubbo project
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Mar 19, 2018 at 9:13 PM jun liu <ke...@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 <jo...@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 <yi...@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.
> >>
> >>
>
>
Re: About the parent pom, groupId and package name of Dubbo project
Posted by jun liu <ke...@gmail.com>.
> - 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?
> On 19 Mar 2018, at 7:56 PM, John D. Ament <jo...@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 <yi...@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.
>>
>>
Re: About the parent pom, groupId and package name of Dubbo project
Posted by "John D. Ament" <jo...@apache.org>.
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 <yi...@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.
>
>
Re: About the parent pom, groupId and package name of Dubbo project
Posted by shang zonghai <yi...@hotmail.com>.
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.
I don’t understand why “ consumer and server upgrades at the same time”? What is the specific compatibility problems, can you give a hint, Zonghai?
What I mean is that the user has extended the dubbo SPI, upgrading dubbo directly at the same time will destroy the original implementation.
Re: About the parent pom, groupId and package name of Dubbo project
Posted by jun liu <ke...@gmail.com>.
> 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.
I don’t understand why “ consumer and server upgrades at the same time”? What is the specific compatibility problems, can you give a hint, Zonghai?
> On 19 Mar 2018, at 7:29 PM, shang zonghai <yi...@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.
>
Re: About the parent pom, groupId and package name of Dubbo project
Posted by Mark Thomas <ma...@apache.org>.
On 19/03/18 11:29, shang zonghai wrote:
<snip/>
> 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.
Possibly just a copy/paste error but note it is *org*.apache
Mark
Re: About the parent pom, groupId and package name of Dubbo project
Posted by shang zonghai <yi...@hotmail.com>.
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.
Re: About the parent pom, groupId and package name of Dubbo project
Posted by Yong Zhu <di...@gmail.com>.
John, I got it, thanks so much.
2018-03-16 18:46 GMT+08:00 John D. Ament <jo...@apache.org>:
> On Fri, Mar 16, 2018 at 3:47 AM Yong Zhu <di...@gmail.com> wrote:
>
> > Hi, all
> >
> > I'm working on this issue:
> >
> > https://issues.apache.org/jira/projects/DUBBO/issues/
> DUBBO-7?filter=allopenissues
> >
> > I have the below questions:
> >
> > 1. Shall we need to change the pom.xml parent to org.apache:apache:19 ?
> Now
> > we use sonatype oss as the central repository.
> >
>
> You don't have to use apache parent pom, however you should expect to build
> against our nexus instance instead of sonatype's oss. If you read through
> the new setup instructions, you can follow them pretty closely except use
> our nexus instance.
>
>
> > 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.
>
>
> >
> > Thanks.
> >
> > Yong Zhu.
> >
>
Re: About the parent pom, groupId and package name of Dubbo project
Posted by "John D. Ament" <jo...@apache.org>.
On Fri, Mar 16, 2018 at 3:47 AM Yong Zhu <di...@gmail.com> wrote:
> Hi, all
>
> I'm working on this issue:
>
> https://issues.apache.org/jira/projects/DUBBO/issues/DUBBO-7?filter=allopenissues
>
> I have the below questions:
>
> 1. Shall we need to change the pom.xml parent to org.apache:apache:19 ? Now
> we use sonatype oss as the central repository.
>
You don't have to use apache parent pom, however you should expect to build
against our nexus instance instead of sonatype's oss. If you read through
the new setup instructions, you can follow them pretty closely except use
our nexus instance.
> 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.
>
> Thanks.
>
> Yong Zhu.
>