Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.5

[Yang Bo]

+1

On Tue, Jan 19, 2021 at 10:23 AM bismy  wrote:

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 2.1.5
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12349435
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.1.5/
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1452
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.1.5
>
> Release CommitID :  ad3bd675d2f305335cb4b4d65866205a5380eb43
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Tuesday, 19 Jan, 2021) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 2.1.5
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
>
> Liu Bao



-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.0

[Yang Bo]

+1 Binding.

Build from source OK.
Rat check OK.

Minor issue:
The github release assets' file name contains version numbers only. Better
to be consistent with the apache dist repo.
https://github.com/apache/servicecomb-java-chassis/archive/2.1.0.zip

On Sun, Jun 28, 2020 at 8:10 PM bismy  wrote:

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 2.1.0
>
> Release Notes : 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12348247
>
> Release Candidate : 
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.1.0/
>
> Staging Repo : 
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1445/
>
> Release Tag : 
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.1.0
>
> Release CommitID :  ccd5bf989bcaf8838a58712f5c41357149d2b0c0
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Monday, 23 March, 2020) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 2.0.2
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
>
> Liu Bao



-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Kie version 0.1.0

[Yang Bo]

Sorry, Seems I checked the wrong source tar ball from github releases.

I re-checked the source release from the apache dist server. It's OK.

On Tue, Oct 22, 2019 at 11:09 AM Yang Bo  wrote:

> +1
>
> I checked the build process from the v0.1.0.tar.gz source release and it's
> OK.
>
> Some minor issues:
> 1. The source tar ball should contain full product name along with
> version. It should be servicecomb-kie-v0.1.0.tar.gz.
> 2. The uncompressed folder name for source release should also follow the
> semVer convention. So it should be servicecomb-kie-v0.1.0. Currently the
> 'v' is missing.
> 3. The licenses folder is for binary release thus should be removed from
> the source release.
>
> On Mon, Oct 21, 2019 at 8:38 PM Xiaoliang Tian 
> wrote:
>
>> Hi All,
>>
>>   This is a call for Vote to release Apache ServiceComb Kie version 0.1.0
>>
>> Release Candidate :
>>
>> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-kie/0.1.0/rc-03/
>>
>>
>>
>> Release Tag :
>> https://github.com/apache/servicecomb-kie/releases/tag/v0.1.0
>>
>> Release CommitID:  65ead3641f33c02055d4365020736d7b4cf34779
>>
>> Release Notes :
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12345632
>>
>>   Keys to verify the Release Candidate :
>> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>>
>> Voting will start now ( Monday, 21nd October , 2019) and will remain open
>>  for at-least 72 hours, Request all PMC members to give their vote.
>>
>> [ ] +1 Release this package as 0.1.0
>> [ ] +0 No Opinion
>> [ ] -1 Do not release this package because
>>
>>  On the behalf of ServiceComb Team
>>
>>
>> Best Wishes & Regards
>>
>
>
> --
> Best Regards,
> Yang.
>


-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Kie version 0.1.0

[Yang Bo]

+1

I checked the build process from the v0.1.0.tar.gz source release and it's
OK.

Some minor issues:
1. The source tar ball should contain full product name along with version.
It should be servicecomb-kie-v0.1.0.tar.gz.
2. The uncompressed folder name for source release should also follow the
semVer convention. So it should be servicecomb-kie-v0.1.0. Currently the
'v' is missing.
3. The licenses folder is for binary release thus should be removed from
the source release.

On Mon, Oct 21, 2019 at 8:38 PM Xiaoliang Tian 
wrote:

> Hi All,
>
>   This is a call for Vote to release Apache ServiceComb Kie version 0.1.0
>
> Release Candidate :
>
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-kie/0.1.0/rc-03/
>
>
>
> Release Tag :
> https://github.com/apache/servicecomb-kie/releases/tag/v0.1.0
>
> Release CommitID:  65ead3641f33c02055d4365020736d7b4cf34779
>
> Release Notes :
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12345632
>
>   Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Monday, 21nd October , 2019) and will remain open
>  for at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 0.1.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
>  On the behalf of ServiceComb Team
>
>
> Best Wishes & Regards
>


-- 
Best Regards,
Yang.

Re: [discuss] change default value of verticle instance count

[Yang Bo]

Is vertical-count a typo? Think it should be verticle-count.

On Fri, Jan 25, 2019 at 5:36 PM wjm wjm  wrote:

> new change:
>   all thread-count rename to vertical-count
>   still allow use old key, but when use old key will print warning log,
> notice it's ambiguous and deprecated, suggest to use new name
>
> 在 2019年1月24日星期四，wjm wjm  写道：
>
> > eventloop will not eat all cpus, OS will schedule all the threads.
> >
> > yhs0092  于2019年1月24日周四 上午9:49写道：
> >
> >> Hi, wjm. Thank you for your sharing.
> >> As you say that if CPU count is less than 8, it's suggested that the
> >> thread-count is set to the CPU count. There is still a doubt for me. In
> the
> >> synchronous mode, since the business logic runs in business thread pool,
> >> i.e. the executor, don't we need to leave some CPU cores for the
> business ?
> >>
> >>
> >> Yours sincerely
> >>
> >>
> >> Yao Haishi
> >> yhs0...@163.com
> >>
> >>
> >> On 1/24/2019 09:38，bismy wrote：
> >> +1
> >>
> >>
> >>
> >>
> >> -- 原始邮件 --
> >> 发件人: "zzzwjm";
> >> 发送时间: 2019年1月24日(星期四) 上午9:30
> >> 收件人: "dev";
> >>
> >> 主题: [discuss] change default value of verticle instance count
> >>
> >>
> >>
> >> currently, we created four type verticle for net send/receive and
> reactive
> >> business logic:
> >>
> >> - rest client verticle
> >> - rest server verticle
> >> - highway client verticle
> >> - highway server verticle
> >>
> >> instances of them controlled by configurations:
> >>
> >> - servicecomb.rest.server.thread-count
> >> - servicecomb.rest.client.thread-count
> >> - servicecomb.highway.server.thread-count
> >> - servicecomb. highway.client.thread-count
> >>
> >> default value of the configurations are set to 1 all, because framework
> >> can
> >> not know what's the best value for them, so we set the conservative
> value
> >>
> >> these default values makes almost all customers need to optimize
> >> the configuration, it's not so good.
> >> so suggest the default values to be:
> >>
> >> - if cpu count less than 8, then thread-count set to cpu count
> >> - if cpu count equals or big than 8, then thread-count set to 8
> >
> >
>


-- 
Best Regards,
Yang.

Re: [discuss] enhance boot log

[Yang Bo]

+1 for collecting the important logs(warnings/errors) into a separate
place.
Perhaps we can also write this collected information both to the console
and to a designated log file.

The boot logs are so long that's almost impossible for someone to get the
meaningful information from them.

On Fri, Jan 25, 2019 at 5:02 PM Willem Jiang  wrote:

> Maybe we can add some lines in the release note to let the user know
> these warning messages are quit important when upgrading the
> java-chassis version.
> It's always good to write some upgrade documents to fill the information
> gap.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Jan 25, 2019 at 4:57 PM wjm wjm  wrote:
> >
> > sometimes, it just a warning, not fatal
> >
> > Willem Jiang  于2019年1月25日周五 下午4:53写道：
> >
> > > If you want user to take a good look of the warning log, you can just
> > > abort the boot process by default.
> > > Just my 2 cents.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Fri, Jan 25, 2019 at 4:43 PM wjm wjm  wrote:
> > > >
> > > > currently, when we find something not so good during boot, we will
> print
> > > > log immediately
> > > > eg:
> > > >
> > > >- use deprecated configuration
> > > >- port listen failed
> > > >- ..
> > > >
> > > > most developers will not notice these important messages
> > > >
> > > > so maybe we can keep current implementation
> > > > and collect all the information, print them after boot
> > > > maybe like:
> > > > *** important message ***
> > > > warning:
> > > >   1.servicecomb.rest.client.thread-count is ambiguous, suggest to use
> > > > servicecomb.rest.client.verticle-count.
> > > > error:
> > > >   1...
> > >
>


-- 
Best Regards,
Yang.

Re: [DISCUSSION] create a new project servicecomb-samples

[Yang Bo]

+1
We can move all the examples for java-chassis and saga to this scb-example
repo.

On Tue, Jan 22, 2019 at 9:52 AM yhs0092  wrote:

> +1
> This is a good idea. Currently the samples of ServiceComb-Java-Chassis is
> mixed in our project code, and the maven dependency management is kind of
> complex. For the new comers, it's a little bit hard to understand and hard
> to run them.
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>
> On 1/21/2019 16:58，Willem Jiang wrote：
> I think it's a good idea to use the sample to demonstrate the usage
> across the subprojects of ServiceComb.
> Current we have an example[1] in servicecomb-pack for using the
> java-chasis with pack. Maybe we can put it as the first example of
> servicecomb-samples.
>
> [1]
> https://github.com/apache/servicecomb-pack/tree/master/demo/saga-servicecomb-demo
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jan 21, 2019 at 3:34 PM bismy  wrote:
>
> Hello all,
>
>
> I suggest the create a new project servicecomb-samples to hosting code of
> servicecomb examples. Currently we have samples in each project, but is not
> enough for reasons:
>
>
> 1. Create new examples will make project huge and hard to distribute.
> 2. We can not create examples based on released version.
> 3. Lack of examples to show integrated features use both of java-chassis
> and saga features.
>
>
> Any ideas?
>


-- 
Best Regards,
Yang.

Re: [Discuss]Adding Etcd as a config center for Java-Chassis

[Yang Bo]

@bismy Could you please contact me on espace and give me a list of what's
need to be done. And also please show me where the code is. I have no idea
about it.

@Willem Jiang   We're not there yet. We need to
cleanup the code and make the licenses right and then go to the IP
clearance.

On Thu, Nov 29, 2018 at 2:28 PM Willem Jiang  wrote:

> If you don't write it from scratch, we need to go through the
> IP-Clearance process[1]
> Otherwise, it could introduce some trouble to ServiceComb project.
>
> [1]http://incubator.apache.org/ip-clearance/
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
> On Wed, Nov 28, 2018 at 11:55 AM Yang Bo  wrote:
> >
> > @bismy
> >
> > Do you mean the config-center opensource? Yes I can do that.
> >
> > On Wed, Nov 28, 2018 at 11:07 AM bismy  wrote:
> >
> > > @Yang Bo
> > >
> > >
> > > Can you start working on service center opensource? I think it's time
> for
> > > this task. And there maybe some tasks need to do, like code clean up,
> > > licences and others staffs. I can find one to help you with these
> works if
> > > needed.
> > >
> > >
> > > I agree with you that servicecomb now seems to be a "lackluster
> system",
> > > but we are in a quite progressive way to build more, and we are
> creating
> > > great components. I am preparing a glossary what we are going to build.
> > >
> > >
> > >
> > >
> > > -- 原始邮件 --
> > > 发件人: "Xiaoliang Tian";
> > > 发送时间: 2018年11月28日(星期三) 上午10:45
> > > 收件人: "dev";
> > >
> > > 主题: Re: [Discuss]Adding Etcd as a config center for Java-Chassis
> > >
> > >
> > >
> > > etcd used by service center is not allowed to expose directly to any
> > > client, this etcd only exposed service center. unless you setup
> isolated
> > > etcd cluster for config management
> > >
> > > Yang Bo  于2018年11月28日周三 上午10:08写道：
> > >
> > > > @Sure
> > > > Yes we can use consul. I choose etcd just because service-center
> already
> > > > uses it. Actually, if we go with consul, we can even drop
> service-center,
> > > > as consul provides service registry/discovery and configuration
> store. We
> > > > can keep the schema data as configuration.
> > > >
> > > > I've been suggesting to opensource the CC and it's frontend since
> > > May/June.
> > > > But here we are, there are still no timeline when this will be done.
> > > > And without this 2 component, the opensource version(servicecomb)
> feels
> > > > like a lackluster system.
> > > >
> > > > On Wed, Nov 28, 2018 at 9:11 AM Willem Jiang  >
> > > > wrote:
> > > >
> > > > > If we have plan to open source the config center and governance,
> > > > > it's could be better we start a discussion here to make a road map.
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > > > > On Wed, Nov 28, 2018 at 8:34 AM wjm wjm  wrote:
> > > > > >
> > > > > > it's better to make huawei config center opensource
> > > > > > after governance opensource, can work with huawei config center
> > > > directly
> > > > > >
> > > > > > Yang Bo  于2018年11月27日周二 下午2:21写道：
> > > > > >
> > > > > > > Etcd in itself is good enough to be used as a config center. I
> > > don't
> > > > > see
> > > > > > > the need for an extra layer, it reduces performance and adds
> > > > > complexity.
> > > > > > >
> > > > > > > For example, if we use Etcd directly, the watch mechanism is
> > > > naturally
> > > > > > > supported by grpc which uses http2, there's no need for using
> > > > websocket
> > > > > > > which might have problems under some firewall rules.
> > > > > > >
> > > > > > > I checked the CC(CSE) client implementation in java-chassis, it
> > > uses
> > > > > vert.x
> > > > > > > and http to talk to the server and use websocket for watching
> when
> > > > > > > possible.
> > &g

Re: [VOTE] Rename of Saga repository

[Yang Bo]

+1 binding

On Wed, Nov 28, 2018 at 5:00 PM 新道场开张了  wrote:

> +1
>
>
>
>
> -- 原始邮件 --
> 发件人: "Willem Jiang";
> 发送时间: 2018年11月28日(星期三) 下午4:23
> 收件人: "dev";
>
> 主题: [VOTE] Rename of Saga repository
>
>
>
> As we discussion before[1], I'd like call for a vote to rename
> servicecomb-saga git repo to servicecomb-pack.
>
> servicecomb-pack is used to provide the TCC and Saga support in the
> pack architecture, we also need to update the artifact group id  to
> replace saga to pack at the meantime.
>
> Voting will start now ( Wednesday, 28th November, 2018) and will
> remain open for at-least 72 hours, Request all PMC members to give
> their vote.
>
> [ ] +1 Rename of servicecomb-service-saga repository to
> servicecomb-service-pack
> [ ] +0 No Opinion
> [ ] -1 Do not Rename the repository because
>
> [1]
> https://lists.apache.org/thread.html/e7468de26b5c956d615fc7c7dbbf03dbde5aef6ac92f5ef843db1dcb@%3Cdev.servicecomb.apache.org%3E
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem



-- 
Best Regards,
Yang.

Re: [Discuss]Adding Etcd as a config center for Java-Chassis

[Yang Bo]

@bismy

Do you mean the config-center opensource? Yes I can do that.

On Wed, Nov 28, 2018 at 11:07 AM bismy  wrote:

> @Yang Bo
>
>
> Can you start working on service center opensource? I think it's time for
> this task. And there maybe some tasks need to do, like code clean up,
> licences and others staffs. I can find one to help you with these works if
> needed.
>
>
> I agree with you that servicecomb now seems to be a "lackluster system",
> but we are in a quite progressive way to build more, and we are creating
> great components. I am preparing a glossary what we are going to build.
>
>
>
>
> -- 原始邮件 --
> 发件人: "Xiaoliang Tian";
> 发送时间: 2018年11月28日(星期三) 上午10:45
> 收件人: "dev";
>
> 主题: Re: [Discuss]Adding Etcd as a config center for Java-Chassis
>
>
>
> etcd used by service center is not allowed to expose directly to any
> client, this etcd only exposed service center. unless you setup isolated
> etcd cluster for config management
>
> Yang Bo  于2018年11月28日周三 上午10:08写道：
>
> > @Sure
> > Yes we can use consul. I choose etcd just because service-center already
> > uses it. Actually, if we go with consul, we can even drop service-center,
> > as consul provides service registry/discovery and configuration store. We
> > can keep the schema data as configuration.
> >
> > I've been suggesting to opensource the CC and it's frontend since
> May/June.
> > But here we are, there are still no timeline when this will be done.
> > And without this 2 component, the opensource version(servicecomb) feels
> > like a lackluster system.
> >
> > On Wed, Nov 28, 2018 at 9:11 AM Willem Jiang 
> > wrote:
> >
> > > If we have plan to open source the config center and governance,
> > > it's could be better we start a discussion here to make a road map.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Wed, Nov 28, 2018 at 8:34 AM wjm wjm  wrote:
> > > >
> > > > it's better to make huawei config center opensource
> > > > after governance opensource, can work with huawei config center
> > directly
> > > >
> > > > Yang Bo  于2018年11月27日周二 下午2:21写道：
> > > >
> > > > > Etcd in itself is good enough to be used as a config center. I
> don't
> > > see
> > > > > the need for an extra layer, it reduces performance and adds
> > > complexity.
> > > > >
> > > > > For example, if we use Etcd directly, the watch mechanism is
> > naturally
> > > > > supported by grpc which uses http2, there's no need for using
> > websocket
> > > > > which might have problems under some firewall rules.
> > > > >
> > > > > I checked the CC(CSE) client implementation in java-chassis, it
> uses
> > > vert.x
> > > > > and http to talk to the server and use websocket for watching when
> > > > > possible.
> > > > >
> > > > > It have implemented tenant, environment separation and we can
> achieve
> > > this
> > > > > by using proper key prefixes in Etcd(v3). I don't see a particular
> > > feature
> > > > > impossible to implement using Etcd only.
> > > > >
> > > > > Besides, it takes a lot of time and effort to opensource the
> > > Config-Center.
> > > > >
> > > > > There is one minor issue for Etcd though. The official Etcd client
> > for
> > > java
> > > > > jetcd is not published to central maven repository yet. They are
> > > preparing
> > > > > an official 0.3.0 release but does not have a timeline for it.
> > > > >
> > > > > On Tue, Nov 27, 2018 at 9:50 AM bismy  wrote:
> > > > >
> > > > > > Do you have any evaluation document by using etcd as config
> center?
> > > Now
> > > > > > config-cc supports using Huawei Config Center as the backend. And
> > > this
> > > > > > implementation is based on ectd with an extra abstraction like
> > > service
> > > > > > center. I am not quite sure if using etcd itself can fitful for
> > > users use
> > > > > > cases and if it is a good solution or just a workable solution.
> > > > > >
> > > > > >
> > > > > > Maybe we can make Huawei C

Re: [Discuss]Adding Etcd as a config center for Java-Chassis

[Yang Bo]

@Sure
Yes we can use consul. I choose etcd just because service-center already
uses it. Actually, if we go with consul, we can even drop service-center,
as consul provides service registry/discovery and configuration store. We
can keep the schema data as configuration.

I've been suggesting to opensource the CC and it's frontend since May/June.
But here we are, there are still no timeline when this will be done.
And without this 2 component, the opensource version(servicecomb) feels
like a lackluster system.

On Wed, Nov 28, 2018 at 9:11 AM Willem Jiang  wrote:

> If we have plan to open source the config center and governance,
> it's could be better we start a discussion here to make a road map.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Nov 28, 2018 at 8:34 AM wjm wjm  wrote:
> >
> > it's better to make huawei config center opensource
> > after governance opensource, can work with huawei config center directly
> >
> > Yang Bo  于2018年11月27日周二 下午2:21写道：
> >
> > > Etcd in itself is good enough to be used as a config center. I don't
> see
> > > the need for an extra layer, it reduces performance and adds
> complexity.
> > >
> > > For example, if we use Etcd directly, the watch mechanism is naturally
> > > supported by grpc which uses http2, there's no need for using websocket
> > > which might have problems under some firewall rules.
> > >
> > > I checked the CC(CSE) client implementation in java-chassis, it uses
> vert.x
> > > and http to talk to the server and use websocket for watching when
> > > possible.
> > >
> > > It have implemented tenant, environment separation and we can achieve
> this
> > > by using proper key prefixes in Etcd(v3). I don't see a particular
> feature
> > > impossible to implement using Etcd only.
> > >
> > > Besides, it takes a lot of time and effort to opensource the
> Config-Center.
> > >
> > > There is one minor issue for Etcd though. The official Etcd client for
> java
> > > jetcd is not published to central maven repository yet. They are
> preparing
> > > an official 0.3.0 release but does not have a timeline for it.
> > >
> > > On Tue, Nov 27, 2018 at 9:50 AM bismy  wrote:
> > >
> > > > Do you have any evaluation document by using etcd as config center?
> Now
> > > > config-cc supports using Huawei Config Center as the backend. And
> this
> > > > implementation is based on ectd with an extra abstraction like
> service
> > > > center. I am not quite sure if using etcd itself can fitful for
> users use
> > > > cases and if it is a good solution or just a workable solution.
> > > >
> > > >
> > > > Maybe we can make Huawei Config Center opensource and distribute it
> like
> > > > service center which is quite simple too.
> > > >
> > > >
> > > > -- 原始邮件 --
> > > > 发件人: "Yang Bo";
> > > > 发送时间: 2018年11月26日(星期一) 晚上7:30
> > > > 收件人: "dev";
> > > >
> > > > 主题: [Discuss]Adding Etcd as a config center for Java-Chassis
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > The ServiceComb project does not have a usable config-center and many
> > > users
> > > > have shown concerns about it. (Apollo is too complex to setup and
> have
> > > high
> > > > learning cure  in using/maintaining).
> > > >
> > > > I tried to build a config-center around Etcd for Java-Chassis, it's
> quite
> > > > simple. Most of the features from the CC(CSE) can be achieved.
> > > >
> > > > From my point of view, using Etcd is good for small projects, show
> cases
> > > > and in development, because we already have an Etcd instance
> > > > running(service-center needs it).
> > > >
> > > > The code is here(it's just a demonstration, needs improvement):
> > > > https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd
> > > >
> > > > Any thoughts?
> > > >
> > > > --
> > > > Best Regards,
> > > > Yang.
> > >
> > >
> > >
> > > --
> > > Best Regards,
> > > Yang.
> > >
>


-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0

[Yang Bo]

+1 Binding

I checked:
1. Rat for binary and source package OK
2. No unwanted binaries in source release OK
3. Build from source OK.
4. License/Notice for source and binary package OK.
5. Basic functionality OK.
6. Checksum and GPG signature OK.


On Tue, Nov 27, 2018 at 2:08 PM Mohammad Asif Siddiqui <
asifdxtr...@apache.org> wrote:

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 1.1.0
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12343569
>
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.1.0/rc-01/
>
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1352
>
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/1.1.0
>
> Release CommitID : 1fa24999399f5d2f8e7dc7bc0972e3f3458f0374
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Tuesday, 27th November, 2018) and will remain open
> for at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 1.1.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
> Mohammad Asif Siddiqui
>


-- 
Best Regards,
Yang.

Re: [Discuss]Adding Etcd as a config center for Java-Chassis

[Yang Bo]

Etcd in itself is good enough to be used as a config center. I don't see
the need for an extra layer, it reduces performance and adds complexity.

For example, if we use Etcd directly, the watch mechanism is naturally
supported by grpc which uses http2, there's no need for using websocket
which might have problems under some firewall rules.

I checked the CC(CSE) client implementation in java-chassis, it uses vert.x
and http to talk to the server and use websocket for watching when possible.

It have implemented tenant, environment separation and we can achieve this
by using proper key prefixes in Etcd(v3). I don't see a particular feature
impossible to implement using Etcd only.

Besides, it takes a lot of time and effort to opensource the Config-Center.

There is one minor issue for Etcd though. The official Etcd client for java
jetcd is not published to central maven repository yet. They are preparing
an official 0.3.0 release but does not have a timeline for it.

On Tue, Nov 27, 2018 at 9:50 AM bismy  wrote:

> Do you have any evaluation document by using etcd as config center? Now
> config-cc supports using Huawei Config Center as the backend. And this
> implementation is based on ectd with an extra abstraction like service
> center. I am not quite sure if using etcd itself can fitful for users use
> cases and if it is a good solution or just a workable solution.
>
>
> Maybe we can make Huawei Config Center opensource and distribute it like
> service center which is quite simple too.
>
>
> ------ 原始邮件 --
> 发件人: "Yang Bo";
> 发送时间: 2018年11月26日(星期一) 晚上7:30
> 收件人: "dev";
>
> 主题: [Discuss]Adding Etcd as a config center for Java-Chassis
>
>
>
> Hi,
>
> The ServiceComb project does not have a usable config-center and many users
> have shown concerns about it. (Apollo is too complex to setup and have high
> learning cure  in using/maintaining).
>
> I tried to build a config-center around Etcd for Java-Chassis, it's quite
> simple. Most of the features from the CC(CSE) can be achieved.
>
> From my point of view, using Etcd is good for small projects, show cases
> and in development, because we already have an Etcd instance
> running(service-center needs it).
>
> The code is here(it's just a demonstration, needs improvement):
> https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd
>
> Any thoughts?
>
> --
> Best Regards,
> Yang.



-- 
Best Regards,
Yang.

[Discuss]Adding Etcd as a config center for Java-Chassis

[Yang Bo]

Hi,

The ServiceComb project does not have a usable config-center and many users
have shown concerns about it. (Apollo is too complex to setup and have high
learning cure  in using/maintaining).

I tried to build a config-center around Etcd for Java-Chassis, it's quite
simple. Most of the features from the CC(CSE) can be achieved.

>From my point of view, using Etcd is good for small projects, show cases
and in development, because we already have an Etcd instance
running(service-center needs it).

The code is here(it's just a demonstration, needs improvement):
https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd

Any thoughts?

-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Service-Center version 1.1.0 [RC-02]

[Yang Bo]

+1 Binding

Checked:
1. Checksum and GPG signature OK.
2. Build from source OK.
3. Rat check on binary/source packages OK.
4. No unintended binaries in source.
5. Basic functionality OK(tested on linux).

Minor issue: The build script assumes that machine doing the build is a
debian based distro on installing nodejs and bower,
it's better we add support for other package managers, yum, zypper etc.


On Mon, Nov 26, 2018 at 6:18 PM Thandayuthapani subramanian <
thanushpa...@gmail.com> wrote:

> +1 non binding
>
> Checks Done:
> - Verified Hashes and Signatures
> - NOTICE/LICENSE files exist
> - ASF Headers present in source files
> - Checked for archive matching git tag
>
> Regards
> Thandayuthapani S
>
> On Fri, Nov 23, 2018 at 10:11 PM Mohammad Asif Siddiqui <
> asifdxtr...@apache.org> wrote:
>
> > Hi All,
> >
> > This is a call for a Vote to release Apache ServiceComb Service-Center
> > version 1.1.0 [RC-02]
> >
> > Release Notes :
> >
> https://github.com/apache/servicecomb-service-center/blob/master/docs/release/releaseNotes-1.1.0.md
> >
> >
> > Release Candidate :
> >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/1.1.0/rc-02/
> >
> >
> > Release Tag :
> > https://github.com/apache/servicecomb-service-center/releases/tag/1.1.0
> >
> > Release CommitID : 49428294a99f2a475203a7ceb04ce8d5754feb77
> >
> > Keys to verify the Release Candidate :
> > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Guide to build the release from source :
> >
> https://github.com/apache/servicecomb-service-center/tree/master/scripts/release
> >
> >
> > Voting will start now ( Friday, 23rd November, 2018) and will remain open
> > for at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 1.1.0
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
> >
>


-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Saga version 0.2.1

[Yang Bo]

+1 binding

Checked:
1. Checksum and GPG signature OK
2. LICENSE/NOTICE OK.
3. Rat for source release OK.
4. Build from source OK.
5. No unintended binary files in source release OK.


On Fri, Nov 23, 2018 at 6:19 PM Sure  wrote:

> +1 binding
>
>
>
>
> -- Original --
> From: Willem Jiang 
> Date: Fri,Nov 23,2018 5:44 PM
> To: dev 
> Subject: Re: [VOTE] Release Apache ServiceComb Saga version 0.2.1
>
>
>
> Hi Walker,
>
> Thanks for you time to verify the kit.
> If you are the PMC[1] member, you can send a binding vote.
> As you are not the PMC member, your vote is no-binding.
>
> [1]http://www.apache.org/dev/pmc.html
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
> On Fri, Nov 23, 2018 at 5:35 PM Walker Han  wrote:
> >
> > +1 binding.I checked:- test via Feign called services.
> > Best Regards,
> > Walker Han
> >
> >
> > 在 2018-11-23 17:17:01，"bismy"  写道：
> > >+1 binding
> > >
> > >
> > >Checks Done:
> > >- release notes
> > >- binaries and maven repos
> > >- some demo tests
> > >
> > >
> > >
> > >
> > >-- 原始邮件 --
> > >发件人: "Mohammad Asif Siddiqui";
> > >发送时间: 2018年11月23日(星期五) 下午5:08
> > >收件人: "dev";
> > >
> > >主题: Re: [VOTE] Release Apache ServiceComb Saga version 0.2.1
> > >
> > >
> > >
> > >+1 binding
> > >
> > >Checks Done :
> > >- hashes and signatures is good
> > >- NOTICE/LICENSE exists
> > >- ran RAT tool
> > >- can make release kit from source
> > >- checked for archive matching git tag
> > >- Source file have ASF headers
> > >
> > >Regards
> > >Asif
> > >
> > >
> > >
> > >On 2018/11/23 08:52:17, Zheng Feng  wrote:
> > >> +1 binding
> > >>
> > >> I checked:
> > >>- LICENSE is fine
> > >>- NOTICE is OK
> > >>- Success to build the source and run the tests
> > >>
> > >> Zheng Feng
> > >>
> > >> Willem Jiang  于2018年11月23日周五 上午8:42写道：
> > >>
> > >> > +1 binding.
> > >> >
> > >> > I checked:
> > >> > - incubating in binary and src kit name
> > >> > - signatures and hashes correct
> > >> > - LICENSE is fine
> > >> > - NOTICE is OK
> > >> > - no unexpected binary files
> > >> > - source files have headers
> > >> > - can build the kit from source with any error
> > >> > - can run the demo with the instruction of README
> > >> >
> > >> >
> > >> > Willem Jiang
> > >> >
> > >> > Twitter: willemjiang
> > >> > Weibo: 姜宁willem
> > >> >
> > >> > On Tue, Nov 20, 2018 at 11:36 PM Mohammad Asif Siddiqui
> > >> >  wrote:
> > >> > >
> > >> > > Hi All,
> > >> > >
> > >> > > This is a call for Vote to release Apache ServiceComb Saga
> version 0.2.1
> > >> > >
> > >> > > Release Notes :
> > >> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12344453
> > >> > >
> > >> > > Release Candidate :
> > >> >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-saga/0.2.1/rc-01/
> > >> > >
> > >> > > Staging Repository :
> > >> >
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1346/
> > >> > >
> > >> > > Release Tag :
> > >> > https://github.com/apache/servicecomb-saga/releases/tag/0.2.1
> > >> > >
> > >> > > Release CommitID : 1484592d6fc84a33ffb7510969437ba448277e82
> > >> > >
> > >> > > Keys to verify the Release Candidate :
> > >> > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> > >> > >
> > >> > > Voting will start now ( Tuesday, 20th November, 2018) and will
> remain
> > >> > open for at-least 72 hours, Request all PMC members to give their
> vote.
> > >> > >
> > >> > > [ ] +1 Release this package as 0.2.1
> > >> > > [ ] +0 No Opinion
> > >> > > [ ] -1 Do not release this package because
> > >> > >
> > >> > > On the behalf of ServiceComb Team
> > >> > > Mohammad Asif Siddiqui
> > >> >
> > >>



-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Service-Center version 1.1.0

[Yang Bo]

Hi, The notice is not updated. I'm doing it and please wait for it to be
finished.

On Wed, Nov 21, 2018 at 3:13 PM Willem Jiang  wrote:

> Hi Sure,
>
> Did you create a JIRA for it?
> We can keep tracking this issue by using the JIRA.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Nov 21, 2018 at 8:24 AM Sure  wrote:
> >
> > Hi, asif. I have checked the RC and found a bug.
> >
> >
> > In multiple DC aggregate case, sdk can’t get the instance event from SC.
> >
> >
> > I think it’s a major bug.
> >
> >
> > -- Original --
> > From: Mohammad Asif Siddiqui 
> > Date: Wed,Nov 21,2018 0:34 AM
> > To: dev 
> > Subject: Re: [VOTE] Release Apache ServiceComb Service-Center version
> 1.1.0
> >
> >
> >
> > Hi All,
> >
> > This is a call for a Vote to release Apache ServiceComb Service-Center
> version 1.1.0
> >
> > Release Notes :
> https://github.com/apache/servicecomb-service-center/blob/master/docs/release/releaseNotes-1.1.0.md
> >
> > Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/1.1.0/rc-01/
> >
> > Release Tag :
> https://github.com/apache/servicecomb-service-center/releases/tag/1.1.0
> >
> > Release CommitID : 0a0b1fd8a8f7b1f7c6fd4badcfde6032ed17f8de
> >
> > Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Guide to build the release from source :
> https://github.com/apache/servicecomb-service-center/tree/master/scripts/release
> >
> > Voting will start now ( Tuesday, 20th November, 2018) and will remain
> open for at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 1.1.0
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
>


-- 
Best Regards,
Yang.

Re: [Heads Up ]Git repository names are changed

[Yang Bo]

@Mabin, I think it's already done. You can visit servicecomb.apache.org now.

On Mon, Nov 12, 2018 at 10:32 AM Bin Ma  wrote:

> Hi @Willem,
>
> Does the domain name of the ServiceComb Website also need to be updated?
> such as,
>   http://servicecomb.incubator.apache.org/
> change to
>   http://servicecomb.apache.org/
>
>
>
> Best Wishes & Regards
> ---
> Mabin
>
>
>
> Bin Ma  于2018年11月12日周一 上午9:29写道：
>
> > Great, I will update my document that guide to use ServiceComb.
> >
> >
> > Best Wishes & Regards
> > ---
> > Mabin
> >
> >
> >
> > Sure  于2018年11月11日周日 下午9:22写道：
> >
> >> Hi guys, the ServiceCenter docs and codes are fixed!
> >>
> >>
> >>
> >>
> >>
> >> 发件人: "zzzwjm";
> >> 发送时间: 2018年11月9日(星期五) 上午10:55
> >> 收件人: "dev";
> >>
> >> 主题: Re: [Heads Up ]Git repository names are changed
> >>
> >>
> >>
> >> Great, thanks~
> >>
> >> Zheng Feng  于2018年11月9日周五 上午10:43写道：
> >>
> >> > Nice work ! I just open the PR to fix in the saga [1]
> >> >
> >> > [1] https://github.com/apache/servicecomb-saga/pull/332
> >> >
> >> > Willem Jiang  于2018年11月9日周五 上午10:02写道：
> >> >
> >> > > I did some clean up on java-chassis, saga, service-center README
> file
> >> > > and removed the DISCLAIM file.
> >> > > I also updated some documents of saga reference in the doc site.
> >> > > There may still have some place need to updated.
> >> > > Please check out the documents and feel free to submit fix for that.
> >> > >
> >> > > Willem Jiang
> >> > >
> >> > > Twitter: willemjiang
> >> > > Weibo: 姜宁willem
> >> > >
> >> > > On Fri, Nov 9, 2018 at 8:59 AM Willem Jiang  >
> >> > > wrote:
> >> > > >
> >> > > > Hi Team,
> >> > > >
> >> > > > As part of way to the Apache TLP, we need to rename the github
> repo
> >> > name.
> >> > > > Now it's done.  Please let me know if something is broken.
> >> > > > I just checked travis CI, it's OK. I'll update the status bage
> link
> >> > > shortly.
> >> > > >
> >> > > >
> >> > > > Willem Jiang
> >> > > >
> >> > > > Twitter: willemjiang
> >> > > > Weibo: 姜宁willem
> >> > >
> >> >
> >
> >
>


-- 
Best Regards,
Yang.

Re: [DISCUSS]Discovery API support filter instances by properties

[Yang Bo]

How about add some patching mechanisms. The server only send information of
changed instances in the query response.
 This will drastically reduce the response size when only a few instances
changes in a huge cluster.

On Fri, Nov 9, 2018 at 9:15 AM bismy  wrote:

> I think we need take more considerations on how users use this API.
> According to what we have done, server side need to cache all query
> results. We can't just say 'We just let the client to find out what they
> want to know' and leave all things to users, because the most important
> part of instance management is how to keep data consistence both on server
> side and client side.
>
>
> For this problem, I intend to agree with @zzzwjm. We didn't see any
> critical problem for the current solution to query all possible instances.
> Maybe current solution will have problem with two conditions met: 1.
> instances is huge; 2. instances up/down very frequently. At this
> conditions, the provided solution seems not work very good too.
>
>
> -- 原始邮件 --
> 发件人: "willem.jiang";
> 发送时间: 2018年11月9日(星期五) 上午8:50
> 收件人: "dev";
>
> 主题: Re: [DISCUSS]Discovery API support filter instances by properties
>
>
>
> I think Sure is just want SC provide some filtering query on the
> server side, we don't need to let the server cached all the query
> result.
> We just let the client to find out what they want to know, server
> don't need to send all the data to the client unless the client wants
> them.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Nov 9, 2018 at 5:47 AM wjm wjm  wrote:
> >
> > that will cause SC cache results by different query parameters, is it too
> > heavy?
> >
> > even has 2k  instances  , but client query by data version, if not
> changed,
> > only response 304 NOT MODIFIED
> > if instances changed, and response size is big, then can response with
> > compress
> > so there is no problem?
> >
> > Sure  于2018年11月7日周三 下午11:36写道：
> >
> > >
> https://github.com/apache/incubator-servicecomb-service-center/issues/482
> > >
> > > Hi guys,
> > >
> > > Our system has 20+ services, and each service has 2k instances at most.
> > > All the instances are grouped by some labels(in Properties).
> > >
> > > We are now querying all the instances from SC, and then filtering
> them by
> > > labels on the client side. This wastes a lot of bandwidth and  has poor
> > > performance. Can SC's API provide the filtering function?
> > >
> > > Thx.



-- 
Best Regards,
Yang.

Re: Congratulations on becoming a TLP!

[Yang Bo]

Congratulations to the whole team for the graduation as a TLP. It's a honor
to be part of the ServiceComb team.
The incubating process taught me a lot about how the ASF works and how to
actually contribute in a opensource project.
Thank you all the mentors for you guidance and support.

On Mon, Oct 22, 2018 at 3:59 PM Zen Lin  wrote:

> Thanks for the guiding work from our mentors,  I actually learn lots of
> from your speech and your mails in ASF mail group.
> Best Regards,
> ---
> Zen Lin
> zenlintechnofr...@gmail.com
> Focused on Micro Service and Apache ServiceComb
>
>
> Willem Jiang  于2018年10月21日周日 上午8:42写道：
>
> > Yeah, it's a great team work.
> > We really appreciate the help from our mentors.
> >
> > Regards,
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, Oct 20, 2018 at 1:27 PM Jean-Baptiste Onofré 
> > wrote:
> > >
> > > Congrats to the whole team !
> > >
> > > Regards
> > > JB
> > >
> > > On 20/10/2018 07:20, Roman Shaposhnik wrote:
> > > > Hi!
> > > >
> > > > as you all probably are aware by know, this week ASF's board
> > > > of directors passed a resolution to establish a ServiceComb TLP.
> > > > My major congratulations to the entire community! It was a great
> > > > journey with only a few small steps left.
> > > >
> > > > There's a series of tasks that you now need to drive to completion
> > > > to formalize your TLP status. You can take a look at how some
> > > > of my previous podlings have done it (look up all the sub jiras):
> > > >https://issues.apache.org/jira/browse/MADLIB-1112
> > > > or you can follow the official guid:
> > > >https://incubator.apache.org/guides/transferring.html
> > > >
> > > > If you have any questions -- please don't hesitate to ask any of
> > > > the [former ;-)] mentors.
> > > >
> > > > Thanks,
> > > > Roman.
> > > >
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> >
>


-- 
Best Regards,
Yang.

Re: [VOTE] Graduate Apache ServiceComb (incubating)

[Yang Bo]

+1 (binding)

On Fri, Sep 14, 2018 at 3:58 PM Willem Jiang  wrote:

> Please vote on the proposal for ServiceComb graduation to TLP to submit to
> the Incubator PMC.
>
> Vote:
> [ ] +1 - Recommend Graduation of Apache ServiceComb as a TLP
> [ ] -1 - Do not recommend graduation of Apache ServiceComb because ….
>
> This vote will stay open for at least 72 hours.
>
> 
>
> Establish the Apache ServiceComb Project
>
> WHEREAS, the Board of Directors deems it to be in the best interests of
> the Foundation and consistent with the Foundation's purpose to establish
> a Project Management Committee charged with the creation and maintenance
> of open-source software, for distribution at no charge to the public,
> related to a microservice framework that provides a set of tools and
> components to make development and deployment of cloud applications
> easier.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache ServiceComb Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache ServiceComb Project be and hereby is
> responsible for the creation and maintenance of software related to a
> microservice framework that provides a set of tools and components to
> make development and deployment of cloud applications easier; and be it
> further
>
> RESOLVED, that the office of "Vice President, Apache ServiceComb" be and
> hereby is created, the person holding such office to serve at the
> direction of the Board of Directors as the chair of the Apache
> ServiceComb Project, and to have primary responsibility for management
> of the projects within the scope of responsibility of the Apache
> ServiceComb Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache ServiceComb
> Project:
>
>  * Aray Chenchu Sukesh
>  * Bao Liu
>  * Eric Lee   
>  * Jean-Baptiste Onofré   
>  * Jimin Wu   
>  * Linzhinan      
>  * Mohammad Asif Siddiqui 
>  * Qi Zhang   
>  * Roman Shaposhnik   
>  * Timothy Chen   
>  * Willem Ning Jiang  
>  * Yang Bo
>  * Yihua Cui  
>  * Yin Xiang  
>  * Zheng Feng 
>  * zhengyangyong  
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Willem Ning Jiang be
> appointed to the office of Vice President, Apache ServiceComb, to serve
> in accordance with and subject to the direction of the Board of
> Directors and the Bylaws of the Foundation until death, resignation,
> retirement, removal or disqualification, or until a successor is
> appointed; and be it further
>
> RESOLVED, that the Apache ServiceComb Project be and hereby is tasked
> with the migration and rationalization of the Apache Incubator
> ServiceComb podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> ServiceComb podling encumbered upon the Apache Incubator PMC are
> hereafter discharged.
>
> Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>


-- 
Best Regards,
Yang.

Re: [Discuss]Java Chassis Support Spring Boot 2.0

[Yang Bo]

Hi,

It seems to me that just changing the spring/springboot version is not
enough. There might be inconsistent implementation details which will
require code change between spring 4.x and spring 5.x.

It's better that we remove spring dependency from those none spring related
modules, and then using profile or a separate dependency pom for managing
the spring version.

Modules depends on spring:
ybo@yangbo:~/repos/incubator-servicecomb-java-chassis$ find . -type f -name
"pom.xml" -exec grep -l spring {} \; | grep -v demo | grep -v samples |
grep -v spring-boot | grep -v tests
./transports/transport-rest/transport-rest-servlet/pom.xml
./archetypes/business-service-jaxrs/target/classes/archetype-resources/pom.xml
./archetypes/business-service-jaxrs/src/main/resources/archetype-resources/pom.xml
./archetypes/business-service-springmvc/target/classes/archetype-resources/pom.xml
./archetypes/business-service-springmvc/src/main/resources/archetype-resources/pom.xml
./archetypes/business-service-springmvc/pom.xml
./archetypes/pom.xml
./java-chassis-distribution/pom.xml
./dynamic-config/config-apollo/pom.xml
./parent/pom.xml
./tracing/tracing-zipkin/pom.xml
./tracing/pom.xml
./java-chassis-dependencies/pom.xml
./pom.xml
./handlers/handler-tracing-zipkin/pom.xml
./providers/pom.xml
./providers/provider-springmvc/pom.xml
./coverage-reports/pom.xml
./swagger/swagger-generator/pom.xml
./swagger/swagger-generator/generator-springmvc/pom.xml
./swagger/swagger-invocation/invocation-springmvc/pom.xml
./swagger/swagger-invocation/invocation-core/pom.xml
./swagger/swagger-invocation/pom.xml
./foundations/foundation-config/pom.xml
./foundations/foundation-test-scaffolding/pom.xml
./foundations/foundation-common/pom.xml



On Thu, Sep 13, 2018 at 9:42 AM 郑扬勇  wrote:

> Hi all:
>Spring boot 2.0 had released for a long time ,so I think we need
> support it as soon as possible.
>Here is our current dependency relationship :
>
>  java-chassis [pom]
> ↑
>  java-chassis-dependencies(import springboot 1.5.x and spring4.3.x etc)
> [pom]
>  ↑
>  java-chassis-parent (docker & jacoco plugin etc) [pom]
>  ↑
>  core,edge,handler etc [jar]
>
>So I think we can do like this for support spring boot 2.0:
>
>   java-chassis [pom]
> ↑
>  * java-chassis-dependencies-springboot2 (FIRST import springboot 2.0.x
> and spring5.0.x ,THEN import java-chassis-dependencies) [pom]
>  ↑
>  spring-boot2-starter-servlet(for support Embedded tomcat) etc [jar]
>
>Any thoughts?
>  Best Regards & Thanks!
>  Yangyong Zheng



-- 
Best Regards,
Yang.

Re: [DRAFT] Graduation resolution proposal

[Yang Bo]

+1

Glad to see that the community have matured and ready for graduation.

On Thu, Sep 13, 2018 at 9:51 AM 郑扬勇  wrote:

> Great!
>  +1
>
>
>
>
>  -- 原始邮件 --
>   发件人: "willem.jiang";
>  发送时间: 2018年9月12日(星期三) 晚上9:51
>  收件人: "dev";
>
>  主题: [DRAFT] Graduation resolution proposal
>
>
>
> As ServiceComb community discussed for the graduation for a while[1]
>  and all the committer are OK to be the member of PMC[2].
>
> Now we have the developer team[3] from Huawei, Talend, Stealth,
> Hyperpilot, RedHat, JingDong,Tencent, Syswin, PICC, Changhong,
> Cainiao.
>
> 3300+ commits on development of three subproject.
> 1350+ PRs on the Github
> 171 contributors
> 800+ issues created
> 700+ issues resolved
>
> dev has 113 subscribers
> 208 emails sent by 28 people, divided into 30 topics in last month
>
> Please check out  Apache Maturity Model Assessment for ServiceComb[4]
> for more information.
>
> I just draft our graduation resolution proposal here. Please comment it.
>
> NOTE
> * I'm proposing myself as initial PMC chair -- Please comment if community
>  is onboard with this or propose other persons as well
>
> [1]
> https://lists.apache.org/thread.html/8e59fef1a9eae9ee90808114b3abbdfdf8c6f24442d7575ee04f5100@%3Cdev.servicecomb.apache.org%3E
> [2]
> https://lists.apache.org/thread.html/2d1e7f17f15fc8ec0d4d293798991e93127534be9cc13334336d228f@%3Cdev.servicecomb.apache.org%3E
> [3]https://servicecomb.incubator.apache.org/developers/team/
> [4]
> https://cwiki.apache.org/confluence/display/SERVICECOMB/Apache+Maturity+Model+Assessment+for+ServiceComb
>
> 
>
> Establish the Apache ServiceComb Project
>
> WHEREAS, the Board of Directors deems it to be in the best interests of
> the Foundation and consistent with the Foundation's purpose to establish
> a Project Management Committee charged with the creation and maintenance
> of open-source software, for distribution at no charge to the public,
> related to a microservice framework that provides a set of tools and
> components to make development and deployment of cloud applications
> easier.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache ServiceComb Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache ServiceComb Project be and hereby is
> responsible for the creation and maintenance of software related to a
> microservice framework that provides a set of tools and components to
> make development and deployment of cloud applications easier; and be it
> further
>
> RESOLVED, that the office of "Vice President, Apache ServiceComb" be and
> hereby is created, the person holding such office to serve at the
> direction of the Board of Directors as the chair of the Apache
> ServiceComb Project, and to have primary responsibility for management
> of the projects within the scope of responsibility of the Apache
> ServiceComb Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache ServiceComb
> Project:
>
>  * Aray Chenchu Sukesh
>  * Bao Liu
>  * Eric Lee   
>  * Jean-Baptiste Onofré   
>  * Jimin Wu   
>  * Linzhinan  
>  * Mohammad Asif Siddiqui 
>  * Qi Zhang   
>  * Roman Shaposhnik   
>  * Timothy Chen   
>  * Willem Ning Jiang  
>  * Yang Bo
>  * Yihua Cui  
>  * Yin Xiang  
>  * Zheng Feng 
>  * zhengyangyong  
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Willem Ning Jiang be
> appointed to the office of Vice President, Apache ServiceComb, to serve
> in accordance with and subject to the direction of the Board of
> Directors and the Bylaws of the Foundation until death, resignation,
> retirement, removal or disqualification, or until a successor is
> appointed; and be it further
>
> RESOLVED, that the Apache ServiceComb Project be and hereby is tasked
> with the migration and rationalization of the Apache Incubator
> ServiceComb podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> ServiceComb podling encumbered upon the Apache Incubator PMC are
> hereafter discharged.
>
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem



-- 
Best Regards,
Yang.

Re: Invitation of the ServiceComb PMC

[Yang Bo]

yes

Eric Lee 于2018年9月8日 周六上午11:18写道：

> Yes
>
> Zhang Qi  於 2018年9月7日 週五 上午10:19寫道：
>
> > yes
> >
> > Willem Jiang  于2018年9月6日周四 上午9:00写道：
> >
> > > Hi Committers
> > >
> > > As the discussion of  "Heading to graduation" [1], we want to setup
> > > the PMC as part of ServiceComb graduation resolution. So we'd like to
> > > confirm whether you want to remain as a Project Management Committees
> > > (PMC) member of Apache ServiceComb project?
> > >
> > > I just quote some roles description of PMC from How it works of
> > Apache[2].
> > > If you just heard about PMC, please spend some time to read about the
> > > role of PMC and understand the responsibilities, and let me know if
> > > you have any question about it.
> > >
> > > " The role of the PMC from a Foundation perspective is oversight. The
> > > main role of the PMC is not code and not coding - but to ensure that
> > > all legal issues are addressed, that procedure is followed, and that
> > > each and every release is the product of the community as a whole.
> > > That is key to our litigation protection mechanisms.
> > >
> > > Secondly the role of the PMC is to further the long term development
> > > and health of the community as a whole, and to ensure that balanced
> > > and wide scale peer review and collaboration does happen. Within the
> > > ASF we worry about any community which centers around a few
> > > individuals who are working virtually uncontested. We believe that
> > > this is detrimental to quality, stability, and robustness of both code
> > > and long term social structures."
> > >
> > > If you'd like to be the member of ServiceComb PMC, it's welcome and
> > > please *respond** 'Yes'* in this thread, or *respond 'No'* if you are
> > > not interested in any more.
> > >
> > > This thread will be available for at least 72 hours, after that, we
> > > will send individual confirm emails.
> > >
> > > [1]
> > >
> >
> https://lists.apache.org/thread.html/3753af01adc9f0db65949565851f66816e1932dde028b99ee7a7c14e@%3Cdev.servicecomb.apache.org%3E
> > > [2]http://www.apache.org/foundation/how-it-works.html#pmc
> > >
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> >
> >
> > --
> > 张琦(Qi)
> >
>
-- 
Best Regards,
Yang.

Re: [DISCUSS] Heading to graduation

[Yang Bo]

+1

On Tue, Sep 4, 2018 at 2:37 PM Zen Lin  wrote:

> Willem  Jiang are doing lots of works on technical guide and  Apache Way
> guide, I would like to recommend he to be the PMC Chair.
>
> Best Regards,
> ---
> Zen Lin
> zenlintechnofr...@gmail.com
> Focused on Micro Service and Apache ServiceComb
>
>
> Kirin Wang  于2018年9月4日周二 下午2:29写道：
>
> > +1
> > Willem did a lot in building the community
> >
> > Lance Ju  于2018年9月4日周二 下午2:26写道：
> >
> > > +1
> > >
> > > Mohammad Asif Siddiqui  于2018年9月4日周二 下午1:42写道：
> > >
> > > > +1
> > > >
> > > > On Tue, Sep 4, 2018 at 8:59 AM Sure  wrote:
> > > >
> > > > > +1
> > > > >
> > > > >
> > > > > -- Original --
> > > > > From: wjm wjm 
> > > > > Date: Tue,Sep 4,2018 11:20 AM
> > > > > To: dev 
> > > > > Subject: Re: [DISCUSS] Heading to graduation
> > > > >
> > > > >
> > > > >
> > > > > +1
> > > > >
> > > > > 郑扬勇 <342906...@qq.com> 于2018年9月4日周二 上午10:54写道：
> > > > >
> > > > > > +1
> > > > > >
> > > > > >
> > > > > >
> > > > > >  -- 原始邮件 --
> > > > > >   发件人: "bismy";
> > > > > >  发送时间: 2018年9月4日(星期二) 上午9:26
> > > > > >  收件人: "willem.jiang";
> > > > > >
> > > > > >  主题: 回复： [DISCUSS] Heading to graduation
> > > > > >
> > > > > >
> > > > > >
> > > > > > I recommend Willem Jiang to be the PMC Chair.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -- 原始邮件 --
> > > > > > 发件人: "willem.jiang";
> > > > > > 发送时间: 2018年9月3日(星期一) 下午4:10
> > > > > > 收件人: "dev";
> > > > > >
> > > > > > 主题: Re: [DISCUSS] Heading to graduation
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Team,
> > > > > >
> > > > > > For the resolution proposal[1], we need to figure out  PMC and
> PMC
> > > > Chair
> > > > > of
> > > > > > the ServiceComb for the board.
> > > > > > Normally we just move our PPMC member to the PMC, and we need to
> > > figure
> > > > > out
> > > > > > the PMC Chair.
> > > > > >
> > > > > > [1]
> > > > >
> > >
> https://incubator.apache.org/guides/graduation.html#preparing_a_charter
> > > > > >
> > > > > >
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > > >
> > > > > > On Thu, Aug 16, 2018 at 12:32 PM, Jean-Baptiste Onofré <
> > > > j...@nanthrax.net>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Willem,
> > > > > > >
> > > > > > > thanks for the update.
> > > > > > >
> > > > > > > The maturity model assessment draft looks overall good to me.
> > > > > > >
> > > > > > > I will add the resolution proposal draft on the wiki as well.
> > > > > > >
> > > > > > > Regards
> > > > > > > JB
> > > > > > >
> > > > > > > On 15/08/2018 11:09, Willem Jiang wrote:
> > > > > > > > With the ServiceComb java-chassis 1.0.0-incubating and
> > > > service-center
> > > > > > > > 1.0.0-incubating release officially out.
> > > > > > > > We believe it is time to discuss what requirements remains to
> > > > > consider
> > > > > > > > graduation to the TLP.
> > > > > > > >
> > > > > > > > I just updated the ServiceComb Project Status for it:
> > > > > > > >
> > > > > > > > http://servicecomb.incubator.apache.org/
> > > > > > > >
> > > > > > > > Apache ServiceComb entered incubation in November of 2017,
> > > > > ServiceComb
> > > > > > > > community learned a lot about how to do things in Apache
> ways.
> > > > > > > > Now we are a very helpful and engaged community, ready to
> help
> > on
> > > > all
> > > > > > > > questions from the ServiceComb Community.
> > > > > > > > We are making consensus decisions through the discussion in
> the
> > > > > mailing
> > > > > > > > list and voted 3 new committers.
> > > > > > > > We managed delivered three round released include 5 different
> > > > binary
> > > > > > > > release, now we can do self-driving releases in good cadence.
> > > > > > > >
> > > > > > > > Please check out the maturity assessment doc[1] for more
> > > > information.
> > > > > > > >
> > > > > > > > [1]
> > > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/SERVICECOMB/Apache+Maturity+
> > > > > > > > Model+Assessment+for+ServiceComb
> > > > > > > >
> > > > > > > > Any thoughts? And welcome advice from ServiceComb Mentors?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Willem Jiang
> > > > > > > >
> > > > > > > > Twitter: willemjiang
> > > > > > > > Weibo: 姜宁willem
> > > > > > > >
> > > > > > > > On Fri, Jul 13, 2018 at 4:16 PM, Jean-Baptiste Onofré <
> > > > > j...@nanthrax.net
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> It sounds good !
> > > > > > > >>
> > > > > > > >> In the mean time, I'm moving forward on the assessment
> > document
> > > > and
> > > > > > > >> preparing the resolution.
> > > > > > > >>
> > > > > > > >> I will send an update during the weekend.
> > > > > > > >>
> > > > > > > >> Regards
> > > > > > > >> JB
> > > > > > > >>
> > > > > > > >> On 13/07/2018 09:44, Willem Jiang wrote:
> > > > > > > >>>

Re: Re: [DISCUSS]add The Sources Panel In Schema Test

[Yang Bo]

Hi,

I'll create a JIRA issue for this task and add the detailed description
there.

Thanks.

On Wed, Aug 29, 2018 at 4:21 PM 肖一梅  wrote:

>
> Hi,
>
> I'd like to take this task. But I'm not sure on the meaning of the shema
> source. Can you tell me the detailed requirements?
>
>
> > -原始邮件-
> > 发件人: "Willem Jiang" 
> > 发送时间: 2018-08-29 10:15:58 (星期三)
> > 收件人: dev@servicecomb.apache.org, "Yang Bo" 
> > 抄送:
> > 主题: Re: [DISCUSS]add The Sources Panel In Schema Test
> >
> > @Yang Bo  ， Asif is on vaction.
> >
> > Please feel free to add a JIRA and let xiaoyimei take it.
> >
> > BTW,  it's great to see we have more and more long time committer who is
> > interested about our project.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> >
> > On Wed, Aug 29, 2018 at 9:28 AM Yang Bo  wrote:
> >
> > > +1.
> > >
> > > Hi Asif,
> > >
> > > The 3 issues assigned to xiaoyimei have all been resolved. Perhaps we
> can
> > > give this one to her?
> > >
> > > On Tue, Aug 28, 2018 at 8:16 PM Mohammad Asif Siddiqui <
> > > asifdxtr...@apache.org> wrote:
> > >
> > > > +1 It will be nice feature and it's always good to add the features
> which
> > > > users really want it and will be using it frequently, we can plan
> this in
> > > > coming 1.1.0 release.
> > > >
> > > > Regards
> > > > Asif
> > > >
> > > > On 2018/08/23 03:48:27, "Sure"  wrote:
> > > > > Now, shema test in the sc frontend does not contain the schema
> source,
> > > > then the developer can not debug it coveniently.
> > > > > So, I suggest add a source panel to shema test
> > > >
> > >
> > >
> > > --
> > > Best Regards,
> > > Yang.
> > >
>
>
> --
> 软件与服务中心
>
>
> 信息安全部：肖一梅
>
>
> 联系电话：18782015125
>
>
> 邮箱：yimei.x...@changhong.com
>


-- 
Best Regards,
Yang.

Re: [DISCUSS]add The Sources Panel In Schema Test

[Yang Bo]

+1.

Hi Asif,

The 3 issues assigned to xiaoyimei have all been resolved. Perhaps we can
give this one to her?

On Tue, Aug 28, 2018 at 8:16 PM Mohammad Asif Siddiqui <
asifdxtr...@apache.org> wrote:

> +1 It will be nice feature and it's always good to add the features which
> users really want it and will be using it frequently, we can plan this in
> coming 1.1.0 release.
>
> Regards
> Asif
>
> On 2018/08/23 03:48:27, "Sure"  wrote:
> > Now, shema test in the sc frontend does not contain the schema source,
> then the developer can not debug it coveniently.
> > So, I suggest add a source panel to shema test
>


-- 
Best Regards,
Yang.

Re: [DISCUSS]Add Vendor Sources Code In SC project

[Yang Bo]

Hi Willem,

OK I got your point. I just checked the Serive-Center's dependencies. It
seems that all the third-parties it depends on are on Category A list(the
go dependencies and JS dependencies).
So we can include the vendor in the source release archive. We will need to
update the LICENSE/NOTICE for source release.

If someday we added a Category B licensed dependency then we cannot include
it in the source release. Luckily those licenses(EPL,MPL,CC-A,CCDL) are
rare on the go ecosystem.

On Mon, Aug 27, 2018 at 11:48 AM Willem Jiang 
wrote:

> I'm not object to put the third party code into git repository.
> My point is if we want to help the user build the kit from source easily,
> we should not delete the vendor directory when doing the source release.
> For the k8s source release[1],  it still includes the vendor directory.
>
> [1]https://dl.k8s.io/v1.11.0/kubernetes-src.tar.gz
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> On Mon, Aug 27, 2018 at 11:27 AM Yang Bo  wrote:
>
> > It's pretty common for go projects to include the vendor directory in
> their
> > repository.
> > https://github.com/kubernetes/kubernetes/tree/master/vendor
> >
> > And it's common knowledge that the code under vendor directory is from
> > third-parties in the go ecosystem. So it seems natural that the
> repository
> > provide the vendor directory for convenience but the source release does
> > not. The user can still build from source following the instructions in
> the
> > README.
> >
> > On Mon, Aug 27, 2018 at 7:52 AM Willem Jiang 
> > wrote:
> >
> > > Apache provides the source release for the user who want to build the
> kit
> > > from scratch.
> > > If there are too much difference between the source release kit and
> that
> > he
> > > get from the git repo with the tag, we need to explain it.
> > > Normally community user only want to use the release version of the
> kit,
> > if
> > > we exclude the vendor source in the release kit, why do we need to put
> > them
> > > into the git repo?
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > >
> > > On Sat, Aug 25, 2018 at 5:52 PM Yang Bo  wrote:
> > >
> > > > +1
> > > >
> > > > As for the Apache compliance, It's OK to include the vendor source
> code
> > > in
> > > > our repository. We can update the release script and exclude the
> vendor
> > > > directory when releasing.
> > > >
> > > > On Sat, Aug 25, 2018 at 4:20 PM Kirin Wang 
> > > > wrote:
> > > >
> > > > > +1
> > > > > But may be we need to confirm if there are Apache compliance  issue
> > > about
> > > > > it ?
> > > > >
> > > > > Xiaoliang Tian  于2018年8月25日周六 上午10:48写道：
> > > > >
> > > > > > +1  Agree
> > > > > > the truth is go project can easily go into a dep hell and there
> is
> > no
> > > > dep
> > > > > > tool can manage the complicated deps
> > > > > >
> > > > > > checkout how go project does
> > > > > > https://github.com/istio/istio/tree/master/vendor
> > > > > > https://github.com/coreos/etcd/tree/master/vendor
> > > > > >
> > > > > > dep management is torturing go developers now
> > > > > >
> > > > > > Sure  于2018年8月25日周六 上午10:39写道：
> > > > > >
> > > > > > > Developers from China complain it is hard to go get the 3rd
> > depends
> > > > > > source
> > > > > > > code of sc.
> > > > > > > I suggest add these source code in vendor directory in sc
> > project,
> > > > like
> > > > > > > Istio and etcd project do.
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best Regards,
> > > > Yang.
> > > >
> > >
> >
> >
> > --
> > Best Regards,
> > Yang.
> >
>


-- 
Best Regards,
Yang.

Re: [DISCUSS]Add Vendor Sources Code In SC project

[Yang Bo]

It's pretty common for go projects to include the vendor directory in their
repository.
https://github.com/kubernetes/kubernetes/tree/master/vendor

And it's common knowledge that the code under vendor directory is from
third-parties in the go ecosystem. So it seems natural that the repository
provide the vendor directory for convenience but the source release does
not. The user can still build from source following the instructions in the
README.

On Mon, Aug 27, 2018 at 7:52 AM Willem Jiang  wrote:

> Apache provides the source release for the user who want to build the kit
> from scratch.
> If there are too much difference between the source release kit and that he
> get from the git repo with the tag, we need to explain it.
> Normally community user only want to use the release version of the kit, if
> we exclude the vendor source in the release kit, why do we need to put them
> into the git repo?
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> On Sat, Aug 25, 2018 at 5:52 PM Yang Bo  wrote:
>
> > +1
> >
> > As for the Apache compliance, It's OK to include the vendor source code
> in
> > our repository. We can update the release script and exclude the vendor
> > directory when releasing.
> >
> > On Sat, Aug 25, 2018 at 4:20 PM Kirin Wang 
> > wrote:
> >
> > > +1
> > > But may be we need to confirm if there are Apache compliance  issue
> about
> > > it ?
> > >
> > > Xiaoliang Tian  于2018年8月25日周六 上午10:48写道：
> > >
> > > > +1  Agree
> > > > the truth is go project can easily go into a dep hell and there is no
> > dep
> > > > tool can manage the complicated deps
> > > >
> > > > checkout how go project does
> > > > https://github.com/istio/istio/tree/master/vendor
> > > > https://github.com/coreos/etcd/tree/master/vendor
> > > >
> > > > dep management is torturing go developers now
> > > >
> > > > Sure  于2018年8月25日周六 上午10:39写道：
> > > >
> > > > > Developers from China complain it is hard to go get the 3rd depends
> > > > source
> > > > > code of sc.
> > > > > I suggest add these source code in vendor directory in sc project,
> > like
> > > > > Istio and etcd project do.
> > > >
> > >
> >
> >
> > --
> > Best Regards,
> > Yang.
> >
>


-- 
Best Regards,
Yang.

Re: About introduce Lombok to service comb

[Yang Bo]

I don't think using lombok in Java-Chassis is a good idea.
It provides little to no value but introduces a lot of headaches for all
developers.
It's much clearer for the code to be explicit other than embedded in
annotations even if that means we need to write a bit more code. And it
pretty easy to use IDE to generate those kind of code anyway.


On Mon, Aug 27, 2018 at 8:31 AM Willem Jiang  wrote:

> Lombok generate the codes during the compile time, we don't need use it in
> the runtime.
> The only shortcoming of Lombok is we need to install the plugin in the IDE
> to make sure the get|set codes are generated rightly, otherwise he will get
> lot of compile complains. That is why I suggest we need to update the
> development environment document if we decide to use it.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> On Sat, Aug 25, 2018 at 6:55 PM 赵俊  wrote:
>
> > Hi，bismy
> >
> > in factor we can import Lombok and make the scope is provided.
> > Then users dependency service Lombok will not see the Lombok jar.
> > We(sharding-sphere) use Lombok like this.
> >
> > 
> > org.projectlombok
> > lombok
> > 1.16.4
> > provided
> > 
> >
> >
> >
> > > On 25 Aug 2018, at 9:27 AM, bismy  wrote:
> > >
> > > @赵俊
> > >
> > >
> > > Glad to hear that. I am not meaning all projects not using lombok. Just
> > providing a framework, we have different concerns. In short:
> > >
> > >
> > > 1. Use as less 3rdparties dependencies as possible.
> > > 2. Make users use different 3rdparties easier.
> > >
> > >
> > > So you can see from java-chassis, we do not depend some very good
> > frameworks like spring, spring boot components and use old fashioned SPI
> > mechanism. But users can use these framework easily in their projects.
> > >
> > >
> > > Although java-chassis do not use lombok, if you find something we did
> > make integrate lombok not possible, please feel free to point out.
> > >
> > >
> > > -- 原始邮件 --
> > > 发件人: "赵俊";
> > > 发送时间: 2018年8月23日(星期四) 上午10:39
> > > 收件人: "dev@servicecomb.apache.org";
> > >
> > > 主题: Re: About introduce Lombok to service comb
> > >
> > >
> > >
> > > Hi
> > >
> > > we often use following lombok annotations, it makes our code clean
> > especially existing too many fields.
> > > Lombok seems to be very stable for us so far.
> > >
> > > 1.@Getter, @Setter
> > > 2. @RequiredAgsConstructor
> > > 3. @NoArgsConstructor(access = AccessLevel.PRIVATE)
> > > 4. @Slf4j
> > > 5. @EqualsAndHashCode
> > > 6. @ToString
> > >
> > >
> > >> On 23 Aug 2018, at 10:03 AM, bismy  wrote:
> > >>
> > >> In my opinion, I'd prefer not include Lombok in our project. Here my
> > reasons:
> > >> 1. It's a convenient tool to write getters and setters, users can
> > include it very easily to their projects.
> > >> 2. For framework, I'd prefer our class do not use Lombok annotations.
> > Because write getters/setters is very potable to very runtime,and quite
> > easy with an IDE.  We can avoid many troubles related to 3rdparty
> > dependencies, licenses and maybe conflicts.
> > >> 3. Some of our customers using Lombok before, there are some know
> > issues regarding to java bean specification or work together with Json
> > libraries. (Sorry I do not have the details)
> > >>
> > >>
> > >> -- 原始邮件 --
> > >> 发件人: "willem.jiang";
> > >> 发送时间: 2018年8月22日(星期三) 下午3:40
> > >> 收件人: "dev";
> > >>
> > >> 主题: Re: About introduce Lombok to service comb
> > >>
> > >>
> > >>
> > >> We could specify it in the environment setup document.
> > >> @Cherry Could you share the experience of Lombok usage in sharding
> > sphere?
> > >>
> > >>
> > >> Willem Jiang
> > >>
> > >> Twitter: willemjiang
> > >> Weibo: 姜宁willem
> > >>
> > >> On Wed, Aug 22, 2018 at 2:13 PM, wjm wjm  wrote:
> > >>
> > >>> everyone clone our code, if need to load by IDE, must install the IDE
> > >>> plugin, i don't think it's a good idear.
> > >>>
> > >>> 2018-08-22 12:33 GMT+08:00 Zheng Feng :
> > >>>
> >  It looks good to me and the lombok supports the JDK 9 ?
> > 
> >  2018-08-22 12:21 GMT+08:00 赵俊 :
> > 
> > > Hi, Willem
> > >
> > > Lombok would not package into our service-comb jar, so there is no
> >  license
> > > issue.
> > > We can set the maven scope is “provide”, it just enhance the java
> > code
> > > byte in compile step.
> > >
> > >
> > >
> > >> On 21 Aug 2018, at 10:57 PM, wjm wjm  wrote:
> > >>
> > >> in fact, getter / setter and so on can be generated by
> IDE(IntelliJ
> > /
> > >> Eclipse) simply
> > >>
> > >> 2018-08-21 22:34 GMT+08:00 Willem Jiang :
> > >>
> > >>> Hi Cherry,
> > >>>
> > >>> Thanks for proposal, it can save us lot of time when we write the
> > >>> java
> > > bean
> > >>> class.
> > >>> As lombok is using MIT license, I don't think we could have the
> >  license
> > >>> issue here.
> > >>>
> > >>> I think we can start it from

Re: 答复: [VOTE] Holding an Apache ServiceComb (incubating) Meetup as a Co-located Event in HC 2018 Shanghai, China, OCT 12.

[Yang Bo]

+1 Non-binding

On Sat, Aug 25, 2018 at 11:34 AM wjm wjm  wrote:

> +1 binding
>
> 2018-08-25 10:53 GMT+08:00 YangYongZheng <342906...@qq.com>:
>
> > That's Great!
> > +1 non-binding.
> >
> > Best Regards!
> > YangYongZheng
> >
> > -邮件原件-
> > 发件人: Zen Lin [mailto:zenlintechnofr...@gmail.com]
> > 发送时间: 2018年8月23日 20:41
> > 收件人: dev 
> > 主题: [VOTE] Holding an Apache ServiceComb (incubating) Meetup as a
> > Co-located Event in HC 2018 Shanghai, China, OCT 12.
> >
> > Hi All,
> > This is a call for Vote to hold an Apache ServiceComb (incubating) Meetup
> > as a Co-located Event in HC 2018 Shanghai,  China, OCT 12.
> >
> > As discussed in the meetup proposal [1], we have plan to hold an Apache
> > ServiceComb (incubating) Meetup, details are listed bellow,
> > - What is the topic focus of the event?
> > Topics are focused on  Apache Way related topics， user-practices
> > /technologies topics of Apache ServiceComb (incubating).
> >
> > - Who is organising the event?
> > PMCs of ServiceComb (incubating) are the organizer
> > - When is the event?
> > OCT 12
> > - How many attendees are expected?
> > 80~120
> > - How much PMC involvement is there already?
> > 5
> > - Which marks are requested?
> > Two marks are requested,
> > 1. Name of "Apache ServiceComb Incubating "
> > 2. "Powered By" Apache Incubator logo of Apache ServiceComb (incubating)
> > - Is this for profit or non-profit? (See "Event Profits And Donations")?
> > non-profit.
> >
> > - Who will do speech for Apache Way related?
> > We are inviting Roman and J M for to help doing the sharing.
> >
> > [1]
> https://www.mail-archive.com/dev@servicecomb.apache.org/msg05081.html
> >
> > Best Regards,
> > ---
> > Zen Lin
> > zenlintechnofr...@gmail.com
> > Focused on Micro Service and Apache ServiceComb
> >
> >
> >
> >
>


-- 
Best Regards,
Yang.

Re: [DISCUSS]Add Vendor Sources Code In SC project

[Yang Bo]

+1

As for the Apache compliance, It's OK to include the vendor source code in
our repository. We can update the release script and exclude the vendor
directory when releasing.

On Sat, Aug 25, 2018 at 4:20 PM Kirin Wang  wrote:

> +1
> But may be we need to confirm if there are Apache compliance  issue about
> it ?
>
> Xiaoliang Tian  于2018年8月25日周六 上午10:48写道：
>
> > +1  Agree
> > the truth is go project can easily go into a dep hell and there is no dep
> > tool can manage the complicated deps
> >
> > checkout how go project does
> > https://github.com/istio/istio/tree/master/vendor
> > https://github.com/coreos/etcd/tree/master/vendor
> >
> > dep management is torturing go developers now
> >
> > Sure  于2018年8月25日周六 上午10:39写道：
> >
> > > Developers from China complain it is hard to go get the 3rd depends
> > source
> > > code of sc.
> > > I suggest add these source code in vendor directory in sc project, like
> > > Istio and etcd project do.
> >
>


-- 
Best Regards,
Yang.

Re: 【Proposal】Close ServiceComb group on github

[Yang Bo]

+1 for removing the ServiceComb organization.

Some issues:
The go-chassiss and related forked third parties are still hosted on this
group. We should migrate those first before closing.


On Wed, Jul 25, 2018 at 4:45 PM Willem Jiang  wrote:

> I think we just need to find a home for
> https://github.com/ServiceComb/ServiceComb-Company-WorkShop
>
> huaweicse could be a way to go.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Jul 25, 2018 at 4:25 PM, bismy  wrote:
>
> > +1.
> > Does huawei has an organization to hosting these contents? Maybe we can
> > move them all there. And I have an organization to host temporary
> contents.
> > https://github.com/huaweicse
> >
> >
> > -- 原始邮件 --
> > 发件人: "Zen Lin";
> > 发送时间: 2018年7月25日(星期三) 下午4:13
> > 收件人: "dev";
> > 抄送: "Xiaoliang Tian";
> > 主题: 【Proposal】Close ServiceComb group on github
> >
> >
> >
> > Hi Guys,
> >
> > As we known, Apache ServiceComb (incubating) is in the "Near Graduation"
> > status.
> > There still a ServiceComb group on the github [1], projects under this
> > group is not in the incubator scope of ServiceComb now, my suggestion is
> to
> > close this group.
> >
> > I  have gone though the projects and find out the corresponding
> maintainers
> > , please transfer the project to other place but not ServiceComb,  as
> > follows,
> >
> > Maintainer: Shawn
> > https://github.com/ServiceComb/go-chassis
> > 
> > https://github.com/ServiceComb/cse-collector
> > 
> > https://github.com/ServiceComb/go-cc-client
> > 
> > https://github.com/ServiceComb/go-archaius
> > 
> > https://github.com/ServiceComb/go-sc-client
> > 
> > https://github.com/ServiceComb/paas-lager
> > 
> > https://github.com/ServiceComb/http-client
> > 
> > https://github.com/ServiceComb/auth
> >
> > Maintainer: Willem
> > https://github.com/ServiceComb/spring-cloud-servicecomb-plugins
> > 
> > https://github.com/ServiceComb/seckill
> > 
> > https://github.com/ServiceComb/incubator-servicecomb-website
> >
> > Maintainer: Asif
> > https://github.com/ServiceComb/incubator-servicecomb-service-center
> >
> > To the project below, it is a official demo of servicecomb, I am not sure
> > how to deal with this, any thoughts?
> > https://github.com/ServiceComb/ServiceComb-Company-WorkShop
> >
> >
> > [1] https://github.com/ServiceComb 
> >
> > Best Regards,
> > ---
> > Zen Lin
> > zenlintechnofr...@gmail.com
> > Focused on Micro Service and Apache ServiceComb
> >
>


-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Service-Center (incubating) version 1.0.0

[Yang Bo]

-1

Several third-party libraries were added but not included in LICENSE file.

github.com/karlseguin/ccache
github.com/gorilla/websocket
css-percentage-circle
vis


On Sat, Jul 21, 2018 at 10:16 AM bismy  wrote:

> +1
> Check the release notes and run some test to binaries.
>
>
> One small improvement, for API Changes in release notes, can you give
> detail description about the changes?
>
>
>
>
> -- 原始邮件 --
> 发件人: "Mohammad Asif Siddiqui";
> 发送时间: 2018年7月21日(星期六) 凌晨4:29
> 收件人: "dev";
>
> 主题: [VOTE] Release Apache ServiceComb Service-Center (incubating) version
> 1.0.0
>
>
>
> Hi All,
>
> This is a call for a Vote to release Apache ServiceComb Service-Center
> (Incubating) version 1.0.0
>
> Release Notes :
> https://github.com/apache/incubator-servicecomb-service-center/blob/master/docs/release/releaseNotes-1.0.0.md
>
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/incubator-servicecomb-service-center/1.0.0/rc-01/
>
>
> Release Tag :
> https://github.com/apache/incubator-servicecomb-service-center/releases/tag/1.0.0
>
>
> Release CommitID : 7590fec4e4447fdd3b2977970d544e88ae3762cf
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/KEYS
>
> Guide to build the release from source :
> https://github.com/apache/incubator-servicecomb-service-center/tree/master/scripts/release
>
>
> Voting will start now ( Saturday, 21st July, 2018) and will remain open
> for next 72 hours, Request all PPMC members to give their vote
>
> [ ] +1 Release this package as 1.0.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
> Mohammad Asif Siddiqui



-- 
Best Regards,
Yang.

Re: [DISCUSS]Simplify Dynamic Config (Apollo) Integration Test in Java Chassis

[Yang Bo]

No, What I mean is that Apollo itself is complex. It have multiple
components and uses eureka for registry/discovery.
So it will take a long time for booting an Apollo instance for testing,
which is the problem we are facing in our test cases. The other problem is
that if used in production, it will require extra man-power to
maintain/setup this config center.

On Wed, Jul 18, 2018 at 2:10 PM Zen Lin  wrote:

> +1  to using this way to reduce load of integration testing.
>
> But I am also interested in what Yangbo mentioned,  "apollo is too complex
> a system for our use case".
> My doubt is is there any way to reduce this complex, any user guide blog
> for it?
>
> Best Regards,
> ---
> Zen Lin
> zenlintechnofr...@gmail.com
> Focused on Micro Service and Apache ServiceComb
>
>
> YangYongZheng <342906...@qq.com> 于2018年7月18日周三 上午11:24写道：
>
> > Yes, we only need test integration mechanism, not Apollo itself
> >
> >
> > Best Regards!
> > YangYongZheng
> >
> >
> > -邮件原件-
> > 发件人: Yang Bo [mailto:oaky...@gmail.com]
> > 发送时间: 2018年7月18日 11:13
> > 收件人: dev@servicecomb.apache.org
> > 主题: Re: [DISCUSS]Simplify Dynamic Config (Apollo) Integration Test in
> Java
> > Chassis
> >
> > For the purpose of testing this is OK. But the real problem here is that
> > apollo is too complex a system for our use case.
> >
> >
> > On Wed, Jul 18, 2018 at 11:01 AM 郑扬勇  wrote:
> >
> > > Hi all：
> > >We had integration with Apollo for support dynamic config in Java
> > > Chassis, our CI will pull up apollo docker containers for test
> > > (nobodyiam/apollo-quick-start and lijasonvip/apollodb), this step is
> > > very slow and easy failed.
> > >I found that we are only use apollo openapi (
> > > https://github.com/ctripcorp/apollo/wiki/Apollo%E5%BC%80%E6%94%BE%E5%B
> > > 9%B3%E5%8F%B0) to get configurations from it, code below :
> > >
> > >  private static RestTemplate rest = new RestTemplate();
> > > ResponseEntity exchange = rest.exchange(composeAPI(),
> > > HttpMethod.GET, entity, String.class);
> > >
> > >   It is a general http GET request, so I think we only need start up a
> > > http server and direct return a default configuration content for this
> > > url in order to simulate the apollo server, that is enough.
> > >
> > >Any thoughts?
> > >
> > >  Best Regards & Thanks!
> > >  Yangyong Zheng
> >
> >
> >
> > --
> > Best Regards,
> > Yang.
> >
> >
> >
> >
>


-- 
Best Regards,
Yang.

Re: [DISCUSS]Simplify Dynamic Config (Apollo) Integration Test in Java Chassis

[Yang Bo]

For the purpose of testing this is OK. But the real problem here is that
apollo is too complex a system for our use case.


On Wed, Jul 18, 2018 at 11:01 AM 郑扬勇  wrote:

> Hi all：
>We had integration with Apollo for support dynamic config in Java
> Chassis, our CI will pull up apollo docker containers for test
> (nobodyiam/apollo-quick-start and lijasonvip/apollodb), this step is very
> slow and easy failed.
>I found that we are only use apollo openapi (
> https://github.com/ctripcorp/apollo/wiki/Apollo%E5%BC%80%E6%94%BE%E5%B9%B3%E5%8F%B0)
> to get configurations from it, code below :
>
>  private static RestTemplate rest = new RestTemplate();
>  ResponseEntity exchange = rest.exchange(composeAPI(),
> HttpMethod.GET, entity, String.class);
>
>   It is a general http GET request, so I think we only need start up a
> http server and direct return a default configuration content for this url
> in order to simulate the apollo server, that is enough.
>
>Any thoughts?
>
>  Best Regards & Thanks!
>  Yangyong Zheng



-- 
Best Regards,
Yang.

Re: [DISCUSS] Service-Center Docker images version numbering

[Yang Bo]

+1 for this. And I also suggest to run both the service-center and frontend
in the docker image.

On Tue, Jul 17, 2018 at 9:25 PM Mohammad Asif Siddiqui <
asifdxtr...@apache.org> wrote:

> Hi All,
>
> There was an issue raised in github[1] of service-center regarding the
> images of SC in docker hub for which we need your feedback.
>
> Problem : Currently there are no docker images of service-center which
> reflects the current state of the service-center. We only make docker
> images when we cut new version and also update the "latest" tag at that
> time. If someone(like Java-Chassis and Saga CI) wants to test their changes
> with the latest Service-Center then they have to either wait for a new
> version to be released or make there own docker image which might be
> sometimes difficult.
>
> Solution : For every successful merge to Service-Center the CI will make a
> new docker image and push it to Dockerhub with the "latest" tag. Whenever a
> new version is cut then we will make a new tag with the version number. So
> the Service-Center tags will look like:
> "latest" : Always represents the latest state of the Service-Center in
> github repo.
> "VersionNumer"(like 1.0.0) : This will be created whenever a new version is
> released.
>
> CI's which are using the SC docker hub images can always use the latest tag
> for their test as well as recent versions of the service-center to check
> backward compatibility.
>
> Since Java-Chassis and Saga CI's uses these SC docker images very
> frequently in their test so we want to know the opinion on this from
> maintainers of Java-Chassis and Saga.
>
> [1]
> https://github.com/apache/incubator-servicecomb-service-center/issues/277
>
> Regards
> Asif
>


-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Java-Chassis (Incubating) version 1.0.0-m2

[Yang Bo]

+1 non-binding

1. Release name OK
2. GPG signature and checksum OK
3. Rat check OK
4. Build from source(Ubuntu 16.04) OK
5. No improper binary files(images, fonts etc.) OK
6. README OK
7. DISCLAIMER, LICENSE, NOTICE OK
8. Basic function test(on linux) OK

On Wed, Jun 13, 2018 at 3:12 PM Mohammad Asif Siddiqui <
asifdxtr...@apache.org> wrote:

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> (Incubating) version 1.0.0-m2
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12342355
>
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/incubator-servicecomb-java-chassis/1.0.0-m2/rc-01/
>
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1282/
>
> Release Tag :
> https://github.com/apache/incubator-servicecomb-java-chassis/releases/tag/1.0.0-m2
>
> Release CommitID : abc08ce36a50536f67374cb94513659a31e8880d
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/KEYS
>
> Voting will start now ( Wednesday, 13th June, 2018) and will remain open
> for next 72 hours, Request all PPMC members to give their vote.
>
> [ ] +1 Release this package as 1.0.0-m2
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
> Mohammad Asif Siddiqui
>
>

-- 
Best Regards,
Yang.

Re: [DISCUSSION] How to migrate configurations from cse to servicecomb prefix

[Yang Bo]

+1 for wjm's idea.
The ultimate goal is to use servicecomb.* everywhere in code and
configurations.
We can provide a compatible layer to read the cse.* configurations and
merge them into servicecomb.* and use serviccomb.* elsewhere in the code.

Perhaps we can also provide a tool to transform all configuration files
from cse.* to servicecomb.* to help user migrate, this should be quite
simple.

On Wed, Jun 13, 2018 at 2:57 PM Willem Jiang  wrote:

> Hi，
>
> I  think we can borrow some idea from Spring Boot.
> There are some configuration change between Spring Boot 2 and Spring Boot
> 1.
> Spring Boot provides configuration change module to the mapping thing, or
> print error message for the changed properties.
>
> Any thought?
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Jun 13, 2018 at 11:08 AM, bismy  wrote:
>
> > Hi,
> >
> >
> > Currently we duplicate configurations for servicecomb prefix to cse
> > prefix, and in code we can read configurations by cse prefix. That is:
> > 1. Config file using servicecomb.x.y, can read in code with
> > getProperty("servicecomb.x.y") and getProperty("cse.x.y")
> > 2. Config file using cse.x.y, can read in code with
> getProperty("cse.x.y")
> >
> >
> > If we use cse prefix in code, this is the most portable way to read both
> > cse.x.y and servicecomb.x.y configurations.
> >
> >
> > However, this will leading us to write code always using cse, this is not
> > our intention. We are asking users/developers to using servicecomb
> > gradually.
> >
> >
> > I suggest we use servicecomb prefix when adding new configuration items.
> > But there maybe some axtra work users need to do. For example,
> >
> >
> > One user's project using cse prefix:
> >
> >
> > cse:
> >function:
> >   a: false
> >   b: false
> >
> >
> > And when we add a new configuration item: servicecomb.funciton.c, users
> > must change the configuration file to one of the following:
> >
> >
> > servicecomb:
> >   function:
> >  a: false
> >  b: false
> >  c: false
> >
> >
> >
> >
> > or
> > cse:
> >function:
> >   a: false
> >   b: false
> >
> > servicecomb:
> >   function:
> >  c: false
> >
> >
> >
> >
> >
> > I think we need to encourage users using servicecomb when upgrading, and
> > developers to use servicecomb  prefix when adding new configuration
> items.
> >
> >
> > Any idea?
>


-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Saga (incubating) version 0.2.0

[Yang Bo]

+1 non-binding

On Mon, Jun 11, 2018 at 11:46 AM, Yang Bo  wrote:

>
>
> 1. Release name OK
> 2. GPG signature and checksum OK
> 3. Rat check OK
> 4. Basic function test OK
> 5. Build from source OK
> 6. README OK
> 7. DISCLAIMER, NOTICE, LICENSE OK
>
> On Mon, Jun 11, 2018 at 9:04 AM, Willem Jiang 
> wrote:
>
>> +1 (binding)
>>
>> I checked:
>> - incubating in binary and src kit name
>> - signatures and hashes correct
>> - LICENSE is fine (third party jars versions are updated)
>> - NOTICE is OK but has wrong year please fix
>> - no unexpected binary files
>> - source files have headers
>> - can build the kit from source with any error
>> - can run the demo with the instruction of README
>>
>>
>> Willem Jiang
>>
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>>
>>
>>
>> Willem Jiang
>>
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>> On Fri, Jun 8, 2018 at 2:29 PM, Mohammad Asif Siddiqui <
>> asifdxtr...@apache.org> wrote:
>>
>> > Hi All,
>> >
>> > This is a call for Vote to release Apache ServiceComb Saga (Incubating)
>> > version 0.2.0
>> >
>> > Release Notes : https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> > projectId=12321626&version=12342425
>> >
>> > Release Candidate : https://dist.apache.org/repos/dist/dev/incubator/
>> > servicecomb/incubator-servicecomb-saga/0.2.0/rc-01/
>> >
>> > Staging Repository : https://repository.apache.org/
>> content/repositories/
>> > orgapacheservicecomb-1271/
>> >
>> > Release Tag : https://github.com/apache/incubator-servicecomb-saga/
>> > releases/tag/0.2.0
>> >
>> > Release CommitID : 1f3c3d1e61a6c7f40df479a43d28b54f335d84ac
>> >
>> > Keys to verify the Release Candidate : https://dist.apache.org/repos/
>> > dist/dev/incubator/servicecomb/KEYS
>> >
>> > Voting will start now ( Friday, 8th June, 2018) and will remain open for
>> > next 72 hours, Request all PPMC members to give their vote.
>> >
>> > [ ] +1 Release this package as 0.2.0
>> > [ ] +0 No Opinion
>> > [ ] -1 Do not release this package because
>> >
>> > On the behalf of ServiceComb Team
>> > Mohammad Asif Siddiqui
>> >
>> >
>>
>
>
>
> --
> Best Regards,
> Yang.
>



-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Saga (incubating) version 0.2.0

[Yang Bo]

1. Release name OK
2. GPG signature and checksum OK
3. Rat check OK
4. Basic function test OK
5. Build from source OK
6. README OK
7. DISCLAIMER, NOTICE, LICENSE OK

On Mon, Jun 11, 2018 at 9:04 AM, Willem Jiang 
wrote:

> +1 (binding)
>
> I checked:
> - incubating in binary and src kit name
> - signatures and hashes correct
> - LICENSE is fine (third party jars versions are updated)
> - NOTICE is OK but has wrong year please fix
> - no unexpected binary files
> - source files have headers
> - can build the kit from source with any error
> - can run the demo with the instruction of README
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Jun 8, 2018 at 2:29 PM, Mohammad Asif Siddiqui <
> asifdxtr...@apache.org> wrote:
>
> > Hi All,
> >
> > This is a call for Vote to release Apache ServiceComb Saga (Incubating)
> > version 0.2.0
> >
> > Release Notes : https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12321626&version=12342425
> >
> > Release Candidate : https://dist.apache.org/repos/dist/dev/incubator/
> > servicecomb/incubator-servicecomb-saga/0.2.0/rc-01/
> >
> > Staging Repository : https://repository.apache.org/content/repositories/
> > orgapacheservicecomb-1271/
> >
> > Release Tag : https://github.com/apache/incubator-servicecomb-saga/
> > releases/tag/0.2.0
> >
> > Release CommitID : 1f3c3d1e61a6c7f40df479a43d28b54f335d84ac
> >
> > Keys to verify the Release Candidate : https://dist.apache.org/repos/
> > dist/dev/incubator/servicecomb/KEYS
> >
> > Voting will start now ( Friday, 8th June, 2018) and will remain open for
> > next 72 hours, Request all PPMC members to give their vote.
> >
> > [ ] +1 Release this package as 0.2.0
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
> >
> >
>



-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Service-Center (incubating) version 1.0.0-m2

[Yang Bo]

+1 non-binding


1. Release name OK
2. GPG signature and checksum OK
3. Rat check OK
4. README OK
5. DISCLAIMER,LICENSE,NOTICE OK
6. Basic function test on linux OK
7. No improper binary files(fonts,images) OK
8. Build from source OK


On Mon, Jun 11, 2018 at 9:51 AM, Sure  wrote:

> +1
>
>
> 1、 Commit id match.
> 2、 Checksum is correct.
>
> 3、 Release name is correct.
> 4、 DISCLAIMER/LICENSE/NOTICE file exist.
> 5、 README is correct.6、 Integration tests passed.
>
>
>
> -- 原始邮件 --
> 发件人: "Mohammad Asif Siddiqui";
> 发送时间: 2018年6月8日(星期五) 晚上6:59
> 收件人: "dev";
>
> 主题: [VOTE] Release Apache ServiceComb Service-Center (incubating) version
> 1.0.0-m2
>
>
>
> Hi All,
>
> This is a call for Vote to release Apache ServiceComb Service-Center
> (Incubating) version 1.0.0-m2
>
> Release Notes : https://github.com/apache/incubator-servicecomb-service-
> center/blob/master/docs/release/releaseNotes-1.0.0-m2.md
>
> Release Candidate : https://dist.apache.org/repos/dist/dev/incubator/
> servicecomb/incubator-servicecomb-service-center/1.0.0-m2/rc-01/
>
> Release Tag : https://github.com/apache/incubator-servicecomb-service-
> center/releases/tag/1.0.0-m2
>
> Release CommitID : b913a2de1b5f7fb2a42ac719fe5891d5f46f349d
>
> Keys to verify the Release Candidate : https://dist.apache.org/repos/
> dist/dev/incubator/servicecomb/KEYS
>
> Guide to build the release from source : https://github.com/apache/
> incubator-servicecomb-service-center/tree/master/scripts/release
>
> Voting will start now ( Friday, 8th June, 2018) and will remain open for
> next 72 hours, Request all PPMC members to give their vote
>
> [ ] +1 Release this package as 1.0.0-m2
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
> Mohammad Asif Siddiqui
>



-- 
Best Regards,
Yang.

Re: [ANN] New ServiceComb committer: Eric Lee (李达港）

[Yang Bo]

Congrats!

On Mon, Jun 11, 2018 at 8:51 AM, wjm wjm  wrote:

>  Congratulations ~
>
> 2018-06-10 15:31 GMT+08:00 Willem Jiang :
>
> > Please join me and the rest of the ServiceComb PPMC members in welcoming
> > our
> > new ServiceComb committer: Eric Lee (李达港).
> >
> > Eric Lee contribute the ServiceComb since last Jun, he is active
> > contributor on saga, java-chassis and website. and we look forward to
> many
> > more contributions in the future.
> >
> > Congratulations to Eric ! Welcome!
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
>



-- 
Best Regards,
Yang.

Re: [Discuss] Should we clean up vendor/github.com/go-ecosystem for ServiceCenter

[Yang Bo]

Hi,

The problem is fixed. I added the version information of the 2 libraries in
manifest and removed the code.

Please check
https://github.com/apache/incubator-servicecomb-service-center/pull/372

On Fri, Jun 8, 2018 at 10:58 AM, Sure  wrote:

> we do not change the code in go-ecosystem package and we can remove these
> files from project
>
>
> Just make sure the same version of this package compiled with etcd
> components when make the release.
>
>
>
>
>
> -- 原始邮件 --
> 发件人: "willem.jiang";
> 发送时间: 2018年6月7日(星期四) 中午11:32
> 收件人: "dev";
>
> 主题: Re: [Discuss] Should we clean up vendor/github.com/go-ecosystem for
> ServiceCenter
>
>
>
> If we changed the code, we should move it third party directory.
> @Asif @Cuiyihua  Could you double check with YangBo？
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Jun 7, 2018 at 10:29 AM, Yang Bo  wrote:
>
> > Hi All,
> >
> > Currently we store github.com/go-ecosystem/grpc-gateway and
> > go-grpc-prometheus under the vendor directory.
> >
> > The vendor directory should only contain manifest file and all other code
> > should be fetched from third party repository.
> >
> > If we have made some modification to those libraries, then we need to
> move
> > them to a proper place.
> >
> > --
> > Best Regards,
> > Yang.
> >
>



-- 
Best Regards,
Yang.

Re: [Discuss] Should we clean up vendor/github.com/go-ecosystem for ServiceCenter

[Yang Bo]

If we do have modified those libraries, it's better we make a fork of them
on github and the use the forks.

It's still better that we use them directly as is to ease later upgrade and
do the work in our code through wrappers.

On Thu, Jun 7, 2018 at 11:32 AM, Willem Jiang 
wrote:

> If we changed the code, we should move it third party directory.
> @Asif @Cuiyihua  Could you double check with YangBo？
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Jun 7, 2018 at 10:29 AM, Yang Bo  wrote:
>
> > Hi All,
> >
> > Currently we store github.com/go-ecosystem/grpc-gateway and
> > go-grpc-prometheus under the vendor directory.
> >
> > The vendor directory should only contain manifest file and all other code
> > should be fetched from third party repository.
> >
> > If we have made some modification to those libraries, then we need to
> move
> > them to a proper place.
> >
> > --
> > Best Regards,
> > Yang.
> >
>



-- 
Best Regards,
Yang.

[Discuss] Should we clean up vendor/github.com/go-ecosystem for ServiceCenter

[Yang Bo]

Hi All,

Currently we store github.com/go-ecosystem/grpc-gateway and
go-grpc-prometheus under the vendor directory.

The vendor directory should only contain manifest file and all other code
should be fetched from third party repository.

If we have made some modification to those libraries, then we need to move
them to a proper place.

-- 
Best Regards,
Yang.

Re: [VOTE] Decide which scheme to be used in the T-shirt that used in community promotion

[Yang Bo]

+A

On Mon, May 21, 2018 at 10:44 AM, bismy  wrote:

> +B scheme B
>
>
> -- Original --
> From:  "DeanLee"<82529...@qq.com>;
> Date:  Mon, May 21, 2018 10:39 AM
> To:  "dev";
> Cc:  "Willem Jiang"; "zenlintechnofreak"<
> zenlintechnofr...@gmail.com>;
> Subject:  [VOTE] Decide which scheme to be used in the T-shirt that used
> in community promotion
>
>
>
> Hi All,
>
>
> We are going to make a batch of T-shirts used in community promotion.
> Now, we have 2 schemes for the T-shirts with different design, scheme A
> and  scheme B.
>
>
> This is a call for Vote to decide which  scheme to be used in the T-shirts.
> You can find 2 schemes reference to  https://github.com/
> microDevOps/T-shirt/blob/master/README.md.
>
>
> Please feel free to vote, maybe you can get the T-shirt with your choice
> in the future.
>
>
>
> Please vote accordingly:
> [ ] +A scheme A
> [ ] +B scheme B
>
>
>
>
>
> Best Regards,---
> Zen Lin
> zenlintechnofr...@gmail.com
> Focused on Micro Service and Apache ServiceComb
>



-- 
Best Regards,
Yang.

Please Update the JIRA Status for Preparing the Next Release

[Yang Bo]

Hi All,

We will release the next version of ServiceComb in late June, and the
feature freeze will happen in the end of May.

I checked all the undone issues of SCB project on apache JIRA today. And
assigned fixVersions to some of the issues.

Please check the issues you report or assigned and update them accordingly.
If the fixVersions is incorrect, please update it.

There are many issues that is unassigned, please assign them or modify the
fixVersions to the next release.(1.0.0 for SC and Chassis, 0.3.0 for Saga).

The attachment is a list of all issues. Please update them by 2018/05/18.



-- 
Best Regards,
Yang.


JIRA_Issues_20180516.xlsx
Description: MS-Excel 2007 spreadsheet

Re: [Discussion]About service instances discovery reliable problems

[Yang Bo]

 We may do something like this:
Keep a copy of the instance/metadata information in clientside, and when
the SC is down, the client can still use the local information to visit
services.


On Wed, May 16, 2018 at 11:15 AM, Willem Jiang 
wrote:

> If we treat the service center as an online service, it should provide 7*24
> services.
> But if we use the standalone service center, it could be challenge for the
> service center provide 7*24 service.
>
> How can we setup the instance refresh strategy?
> We may need to provide different solution for different user case.
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, May 14, 2018 at 4:52 PM, bismy  wrote:
>
> > Supporting gray release need a lot of facilities to make it work and
> > service center upgrading can not apply gray release sometimes.
> > And other scenarios like standalone application(not cloud services)
> > restart is quite common. And base services restart can't influence user's
> > service communication.
> >
> >
> > -- 原始邮件 --
> > 发件人: "wjm wjm";
> > 发送时间: 2018年5月14日(星期一) 下午4:23
> > 收件人: "dev@servicecomb.apache.org";
> >
> > 主题: Re: [Discussion]About service instances discovery reliable problems
> >
> >
> >
> > it's a problem, but why business use gray release, but we reject to the
> > solution?
> >
> > 2018年5月14日星期一，bismy  写道：
> >
> > > When service center all instances stoped and then started. This is
> normal
> > > when we are doing maintenance. e.g. upgrading
> > >
> > >
> > >
> > >
> > > -- 原始邮件 --
> > > 发件人: "wjm wjm";
> > > 发送时间: 2018年5月14日(星期一) 中午12:36
> > > 收件人: "dev";
> > >
> > > 主题: Re: [Discussion]About service instances discovery reliable problems
> > >
> > >
> > >
> > > " When service center restarted"
> > >
> > > that means one instance of SC cluster, or whole SC cluster?
> > > even one instance restart will clear all information?
> > >
> > > 2018-05-14 12:03 GMT+08:00 bismy :
> > >
> > > > Hi All,
> > > >
> > > >
> > > > Now we meet a reliable problem. When service center restarted, It
> will
> > > > clear all service instances information.
> > > > And when SDK(java-chassis) queries instance list periodically, it
> will
> > > get
> > > > an empty list and invocation will fail.
> > > >
> > > >
> > > > In order to resolve this problem, two solutions is suggested:
> > > > 1. service center provide instances persistence mechanism. When
> service
> > > > center restarted, it will restore instance information,
> > > > and re-calculate the timeout information(e.g. reset instance last
> > active
> > > > time to startup time). If he gets the heartbeat from instance, the
> > > instance
> > > > will not be removed, and after timeout,
> > > > it can removed instances, like the normal way.
> > > >  2. SDK need to take special care with instances remove. SDK don't
> > > > actually remove instances when he gets empty list from service center
> > and
> > > > it will ping the instances. If ping return
> > > > OK, the instance will not removed.
> > > >
> > > >
> > > > Known consequencies:
> > > > Solution 2:
> > > >   a. Conflicts with service center white/black rule.
> > > >   b. In docker or some instances changed frequently scenario, the
> > ip/port
> > > > is reused by many services when service start/stop, and service
> health
> > > URL
> > > > may also be the same. So it will give a lot of 400 like error when
> > > > instances is not updated.
> > > >
> > > >
> > > > Any suggestions?
> >
>



-- 
Best Regards,
Yang.

Re: [Discussion] about publish invocation event

[Yang Bo]

Sorry, replied to the wrong mail.


On Wed, May 16, 2018 at 11:35 AM, Yang Bo  wrote:

> We may do something like this:
> Keep a copy of the instance/metadata information in clientside, and when
> the SC is down, the client can still use the local information to visit
> services.
>
> On Wed, May 16, 2018 at 11:01 AM, Willem Jiang 
> wrote:
>
>> Hi Wujimin
>>
>> Could you write some code snippet for using the lambda in the EventBus?
>> As you said earlier, the EventBus uses reflection which may cause some
>> performance issue.
>> But I don't know how the lambda can to the same thing in EventBus.
>>
>>
>> Willem Jiang
>>
>> Blog: http://willemjiang.blogspot.com (English)
>>   http://jnn.iteye.com  (Chinese)
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>> On Wed, May 16, 2018 at 8:49 AM, wjm wjm  wrote:
>>
>> >  i have tested dynamic lambda, very fast, almost equals direct call
>> > so abandon interface solution  at last
>> > still use guava EventBus
>> > if cause performance problem, then rewrite a compatible EventBus
>> >
>> > static  T createLambda(Object instance, Method instanceMethod,
>> > Class functionalIntfCls)
>> > throws Throwable {
>> >   Method intfMethod = findAbstractMethod(functionalIntfCls);
>> >
>> >   MethodType invokedType = MethodType.methodType(functionalIntfCls,
>> > instance.getClass());
>> >   MethodType intfMethodType =
>> > MethodType.methodType(intfMethod.getReturnType(),
>> > intfMethod.getParameterTypes());
>> >   MethodHandle methodHandle = lookup.unreflect(instanceMethod);
>> >   MethodType instanceMethodType = MethodType
>> >   .methodType(instanceMethod.getReturnType(),
>> > instanceMethod.getParameterTypes());
>> >
>> >   CallSite callSite = LambdaMetafactory.metafactory(
>> >   lookup,
>> >   intfMethod.getName(),
>> >   invokedType,
>> >   intfMethodType,
>> >   methodHandle,
>> >   instanceMethodType
>> >   );
>> >   //noinspection unchecked
>> >   return (T) callSite.getTarget().invoke(instance);
>> > }
>> >
>> >
>> >
>> > Round 0:
>> > direct:281
>> > reflect:341
>> > lambda:297
>> >
>> > Round 1:
>> > direct:262
>> > reflect:329
>> > lambda:263
>> >
>> > Round 2:
>> > direct:259
>> > reflect:321
>> > lambda:259
>> >
>> > Round 3:
>> > direct:259
>> > reflect:322
>> > lambda:261
>> >
>> > Round 4:
>> > direct:255
>> > reflect:325
>> > lambda:259
>> >
>> >
>> > 2018-05-14 11:00 GMT+08:00 wjm wjm :
>> >
>> > > no instanceOf, no reflection during invoke
>> > > only get all interfaces from class when register a listener instance
>> > >
>> > > 2018-05-14 10:43 GMT+08:00 Willem Jiang :
>> > >
>> > >> We need to limited the events types, otherwise it could cause some
>> > trouble
>> > >> if the listener interesting bunch of events.
>> > >> BTW, can we set the event class type to the Listener?
>> > >> I'm not sure how much efforts the instanceOf operation need.
>> > >> If it is as heavy as the reflection, we may be back to the start
>> point.
>> > >>
>> > >>
>> > >> Willem Jiang
>> > >>
>> > >> Blog: http://willemjiang.blogspot.com (English)
>> > >>   http://jnn.iteye.com  (Chinese)
>> > >> Twitter: willemjiang
>> > >> Weibo: 姜宁willem
>> > >>
>> > >> On Mon, May 14, 2018 at 9:25 AM, wjm wjm  wrote:
>> > >>
>> > >> > class XxxListener implements AListener,BListener...{
>> > >> > }
>> > >> >
>> > >> > All listener interfaces extends from a center type
>> > >> > when we got a listener instance, then loop all it's interfaces and
>> > cache
>> > >> > them
>> > >> > when publish event, get listener instance from cache and invoke
>> > >> >
>> > >> > 2018-05-13 10:07 GMT+08:00 Willem Jiang :
>> > >> >
>> > >> > > +1 for the performance enhancement.
>> > >> > > If it make sense we could let the event listener to 

Re: [Discussion] about publish invocation event

[Yang Bo]

We may do something like this:
Keep a copy of the instance/metadata information in clientside, and when
the SC is down, the client can still use the local information to visit
services.

On Wed, May 16, 2018 at 11:01 AM, Willem Jiang 
wrote:

> Hi Wujimin
>
> Could you write some code snippet for using the lambda in the EventBus?
> As you said earlier, the EventBus uses reflection which may cause some
> performance issue.
> But I don't know how the lambda can to the same thing in EventBus.
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, May 16, 2018 at 8:49 AM, wjm wjm  wrote:
>
> >  i have tested dynamic lambda, very fast, almost equals direct call
> > so abandon interface solution  at last
> > still use guava EventBus
> > if cause performance problem, then rewrite a compatible EventBus
> >
> > static  T createLambda(Object instance, Method instanceMethod,
> > Class functionalIntfCls)
> > throws Throwable {
> >   Method intfMethod = findAbstractMethod(functionalIntfCls);
> >
> >   MethodType invokedType = MethodType.methodType(functionalIntfCls,
> > instance.getClass());
> >   MethodType intfMethodType =
> > MethodType.methodType(intfMethod.getReturnType(),
> > intfMethod.getParameterTypes());
> >   MethodHandle methodHandle = lookup.unreflect(instanceMethod);
> >   MethodType instanceMethodType = MethodType
> >   .methodType(instanceMethod.getReturnType(),
> > instanceMethod.getParameterTypes());
> >
> >   CallSite callSite = LambdaMetafactory.metafactory(
> >   lookup,
> >   intfMethod.getName(),
> >   invokedType,
> >   intfMethodType,
> >   methodHandle,
> >   instanceMethodType
> >   );
> >   //noinspection unchecked
> >   return (T) callSite.getTarget().invoke(instance);
> > }
> >
> >
> >
> > Round 0:
> > direct:281
> > reflect:341
> > lambda:297
> >
> > Round 1:
> > direct:262
> > reflect:329
> > lambda:263
> >
> > Round 2:
> > direct:259
> > reflect:321
> > lambda:259
> >
> > Round 3:
> > direct:259
> > reflect:322
> > lambda:261
> >
> > Round 4:
> > direct:255
> > reflect:325
> > lambda:259
> >
> >
> > 2018-05-14 11:00 GMT+08:00 wjm wjm :
> >
> > > no instanceOf, no reflection during invoke
> > > only get all interfaces from class when register a listener instance
> > >
> > > 2018-05-14 10:43 GMT+08:00 Willem Jiang :
> > >
> > >> We need to limited the events types, otherwise it could cause some
> > trouble
> > >> if the listener interesting bunch of events.
> > >> BTW, can we set the event class type to the Listener?
> > >> I'm not sure how much efforts the instanceOf operation need.
> > >> If it is as heavy as the reflection, we may be back to the start
> point.
> > >>
> > >>
> > >> Willem Jiang
> > >>
> > >> Blog: http://willemjiang.blogspot.com (English)
> > >>   http://jnn.iteye.com  (Chinese)
> > >> Twitter: willemjiang
> > >> Weibo: 姜宁willem
> > >>
> > >> On Mon, May 14, 2018 at 9:25 AM, wjm wjm  wrote:
> > >>
> > >> > class XxxListener implements AListener,BListener...{
> > >> > }
> > >> >
> > >> > All listener interfaces extends from a center type
> > >> > when we got a listener instance, then loop all it's interfaces and
> > cache
> > >> > them
> > >> > when publish event, get listener instance from cache and invoke
> > >> >
> > >> > 2018-05-13 10:07 GMT+08:00 Willem Jiang :
> > >> >
> > >> > > +1 for the performance enhancement.
> > >> > > If it make sense we could let the event listener to subscribe a
> > center
> > >> > type
> > >> > > of event.
> > >> > > My question is how can we describe the event that the listener is
> > >> > > interested?
> > >> > >
> > >> > >
> > >> > >
> > >> > > Willem Jiang
> > >> > >
> > >> > > Blog: http://willemjiang.blogspot.com (English)
> > >> > >   http://jnn.iteye.com  (Chinese)
> > >> > > Twitter: willemjiang
> > >> > > Weibo: 姜宁willem
> > >> > >
> > >> > > On Sat, May 12, 2018 at 4:31 PM, wjm wjm 
> wrote:
> > >> > >
> > >> > > > currently we publish invocation start/startProcess/finish event
> > for
> > >> > every
> > >> > > > invocation
> > >> > > > now event based on guava EventBus
> > >> > > > it's easy to use.
> > >> > > >
> > >> > > > but EventBus based on reflection, performance is not the best.
> > >> > > > in the furture maybe we will add more invocaiton event, and more
> > >> module
> > >> > > > will subscribe invocation event.
> > >> > > >
> > >> > > > so i want to publish invocation event, change from EventBus
> event
> > to
> > >> > > event
> > >> > > > listener loaded by SPI.
> > >> > > >
> > >> > > > what's you suggestion?
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>



-- 
Best Regards,
Yang.

Re: [VOTE] Move github notifications to maillist "comm...@servicecomb.apache.org"

[Yang Bo]

+1 (non-binding)

On Fri, May 11, 2018 at 4:51 PM, kirin wang  wrote:

> Hi  Community:
>
>   As we already discussed  in [1], this is a call for vote to move
> github notifications of Apache ServiceComb to maillist  "
> comm...@servicecomb.apache.org" .
>
> Voting will start now ( Friday, 11th May, 2018) and will remain open for
> next 72 hours.
>
> [ ] +1 Move Github notifications to maillist "commits@servicecomb.apache.
> org
> "
> [ ] +0 No Opinion
> [ ] -1 Do not move Github notifications to maillist "
> comm...@servicecomb.apache.org"
>
>
>
> [1]
> https://lists.apache.org/thread.html/95f538f676326bd2cb1a06cf278c40
> 76352b987bfbabad6c6ae247bc@%3Cdev.servicecomb.apache.org%3E
>



-- 
Best Regards,
Yang.

Re: [Discussion]Java Chassis Support Gracefully Shutdown

[Yang Bo]

Yes, I'll send an email of all the status of ongoing issues by tomorrow. We
can discuss this then.

On Mon, May 7, 2018 at 5:34 PM, Zen Lin  wrote:

> Hi YanBo,
>
> I think which release version can conclude the graceful shutdown is just
> another topic,
> but task about support graceful shutdown function in ServiceComb can be
> start from now.
>
> Best Regards,
> ---
> Zen Lin
> zenlintechnofr...@gmail.com
> Focused on Micro Service and Apache ServiceComb
>
> 2018-05-07 17:30 GMT+08:00 Yang Bo :
>
> > Do we have enough time to put this into 1.0.0-m2? I think we should
> release
> > m2 in early June.
> >
> > On Mon, May 7, 2018 at 5:27 PM, Zen Lin 
> > wrote:
> >
> > > +1
> > > I think it will be very useful to the users , and users like Fujian
> > Mobile
> > > and Chinese People's Insurance also have repeatedly requested.
> > >
> > > Best Regards,
> > > ---
> > > Zen Lin
> > > zenlintechnofr...@gmail.com
> > > Focused on Micro Service and Apache ServiceComb
> > >
> > > 2018-05-07 17:21 GMT+08:00 Willem Jiang :
> > >
> > > > Yeah,  Let's put it into our 1.0.0-m2 release plan.
> > > >
> > > > Yangyong, do you mind create a JIRA for it?
> > > > We can keep track it in our release plan.
> > > >
> > > >
> > > > Willem Jiang
> > > >
> > > > Blog: http://willemjiang.blogspot.com (English)
> > > >   http://jnn.iteye.com  (Chinese)
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Mon, May 7, 2018 at 4:48 PM, 郑扬勇  wrote:
> > > >
> > > > > Hi, All:
> > > > >We did not implement gracefully shutdown yet:
> > > > >
> > > > >// 当程序退出时，进行相关清理，注意：kill -9 {pid}下无效
> > > > >   // 1. 去注册实例信息
> > > > >   // TODO 服务优雅退出
> > > > >   if (applicationContext instanceof
> > > AbstractApplicationContext) {
> > > > > ((AbstractApplicationContext) applicationContext).
> > > > > registerShutdownHook();
> > > > >   }
> > > > >
> > > > >And had got an issue : https://github.com/apache/
> > > > > incubator-servicecomb-java-chassis/issues/685 from user.
> > > > >So i think it's time we must do it and remove this TODO ?
> > > > >
> > > > >  Best Regards!
> > > > >  YangYongZheng
> > > >
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Yang.
> >
>



-- 
Best Regards,
Yang.

Re: [Discussion]Java Chassis Support Gracefully Shutdown

[Yang Bo]

Do we have enough time to put this into 1.0.0-m2? I think we should release
m2 in early June.

On Mon, May 7, 2018 at 5:27 PM, Zen Lin  wrote:

> +1
> I think it will be very useful to the users , and users like Fujian Mobile
> and Chinese People's Insurance also have repeatedly requested.
>
> Best Regards,
> ---
> Zen Lin
> zenlintechnofr...@gmail.com
> Focused on Micro Service and Apache ServiceComb
>
> 2018-05-07 17:21 GMT+08:00 Willem Jiang :
>
> > Yeah,  Let's put it into our 1.0.0-m2 release plan.
> >
> > Yangyong, do you mind create a JIRA for it?
> > We can keep track it in our release plan.
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> >   http://jnn.iteye.com  (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, May 7, 2018 at 4:48 PM, 郑扬勇  wrote:
> >
> > > Hi, All:
> > >We did not implement gracefully shutdown yet:
> > >
> > >// 当程序退出时，进行相关清理，注意：kill -9 {pid}下无效
> > >   // 1. 去注册实例信息
> > >   // TODO 服务优雅退出
> > >   if (applicationContext instanceof
> AbstractApplicationContext) {
> > > ((AbstractApplicationContext) applicationContext).
> > > registerShutdownHook();
> > >   }
> > >
> > >And had got an issue : https://github.com/apache/
> > > incubator-servicecomb-java-chassis/issues/685 from user.
> > >So i think it's time we must do it and remove this TODO ?
> > >
> > >  Best Regards!
> > >  YangYongZheng
> >
>



-- 
Best Regards,
Yang.

Re: [Discuss]Feature list for next releases.

[Yang Bo]

Yes rxJava observable is not implemented yet. We will need to implement it
in this release.

On Thu, May 3, 2018 at 10:02 AM, wjm wjm  wrote:

>  4. Support custom handling of messages while marshaling/unmarshaling.
> (373)
> description is not good.
> all version support customize Serializer/Deserializer, but now
> developers have chances to provide a thread local context for customize
> Serializer/Deserializer
>
> 9. Asynchronous programming model support(AsyncRestTemplate, rxJava
> Observable). (444)
> we did not add rxJava support, right?
>
> 2018-05-02 17:42 GMT+08:00 郑扬勇 :
>
> > Hi :
> >Will complete these PR in this round release :
> >1. Java chassis archetypes are making improvement for publish :
> > https://github.com/apache/incubator-servicecomb-java-chassis/pull/682
> >2. Versions of Spring, Spring Boot and Spring Cloud will upgrade :
> > https://github.com/apache/incubator-servicecomb-java-chassis/pull/673
> >
> >  Best Regards!
> >  YangYong Zheng
> >
> >  -- 原始邮件 --
> >   发件人: "willem.jiang";
> >  发送时间: 2018年5月2日(星期三) 上午10:33
> >  收件人: "dev";
> >
> >  主题: Re: [Discuss]Feature list for next releases.
> >
> >
> >
> > Hi,
> >
> > Thanks for YangBo's good summary of what we already done last month, some
> > of them already have the JIRA number.
> > But we need to know the status of them (if it is resolved or not)
> >
> > I think we need to plan the key features which we plan to finish this
> round
> > release.
> > Such as, Java 9 and Spring Boot 2.0 support  of Java Chassis
> >
> >
> > Any thoughts?
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> >   http://jnn.iteye.com  (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, May 2, 2018 at 9:55 AM, Yang Bo  wrote:
> >
> > > Hi, All:
> > >
> > > Below are features that I collected for the next releases. Please check
> > > whether they are correct and supplement ones that's missed.
> > >
> > > Please also check whether the version number and release dates are OK.
> > >
> > > Release 1 (around 05.30)
> > >
> > > Service-Center 1.0.0-m2
> > > 1. Supports range delete in registry command.
> > > 2. Implement Test Schema function in frontend/backend.
> > > 3. Make the service-center version forward compatible.
> > > 4. Frontend uses proxy to access service-center, this allows the user
> to
> > > access the frontend service without limiting the listening address of
> > > service-center.
> > > 5. Show detailed error message in frontend.
> > >
> > > Java-Chassis 1.0.0-m2
> > > 1. Improve metrics support. (353、359、383、384、385)
> > > 2. Support file/stream transportation to support multi-media
> > > contents(music,pictures). (201)
> > > 3. Support schema/operation level of QPS control. (352)
> > > 4. Support custom handling of messages while marshaling/unmarshaling.
> > (373)
> > > 5. Add "environment" configuration for micro-services. (424)
> > > 6. Add archetypes for java-chassis. (439、440、441、442、470)
> > > 7. Add demo to show how to include java-chassis in gradle. (457)
> > > 8. Improve auto-discovery of service-center instances. (457)
> > > 9. Asynchronous programming model support(AsyncRestTemplate, rxJava
> > > Observable). (444)
> > >
> > > Saga 0.2.0
> > > 1. Load-balance support for omega. (340)
> > > 2. Multiple tenant support. (341)
> > > 3. SSL support for gRPC. (342)
> > > 4. Support dubbo/SpringCloud.
> > > 5. Support sub-transaction retry on failure.
> > >
> > > Release 2 (around 07.30)
> > > Service-Center:
> > >
> > > Java-Chassis:
> > > 1. Support Java9/Java10.
> > > 2. Support generics in highway. (267)
> > >
> > > Saga:
> > > 1. Support Java9/Java10.
> > > 2. Compensation on service instead of on instance. (522)
> > >
> > > --
> > > Best Regards,
> > > Yang.
> > >
> >
>



-- 
Best Regards,
Yang.

Re: [Discuss]Feature list for next releases.

[Yang Bo]

For Java 9/10 support, we will need to wait for the following packages'
support for Java9/10.
grpc-java  NG
vert.xOK
netty OK
spring   OK
mockit   NG?
...

It's better to put this into a later release instead of 1.0.0-m2.

On Wed, May 2, 2018 at 10:39 AM, kirin wang  wrote:

> +1 for Java 9 support
> May be we should  also have a plan to test the  compatibility of Java 10 ~~
>
> 2018-05-02 10:33 GMT+08:00 Willem Jiang :
>
> > Hi,
> >
> > Thanks for YangBo's good summary of what we already done last month, some
> > of them already have the JIRA number.
> > But we need to know the status of them (if it is resolved or not)
> >
> > I think we need to plan the key features which we plan to finish this
> round
> > release.
> > Such as, Java 9 and Spring Boot 2.0 support  of Java Chassis
> >
> >
> > Any thoughts?
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> >   http://jnn.iteye.com  (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, May 2, 2018 at 9:55 AM, Yang Bo  wrote:
> >
> > > Hi, All:
> > >
> > > Below are features that I collected for the next releases. Please check
> > > whether they are correct and supplement ones that's missed.
> > >
> > > Please also check whether the version number and release dates are OK.
> > >
> > > Release 1 (around 05.30)
> > >
> > > Service-Center 1.0.0-m2
> > > 1. Supports range delete in registry command.
> > > 2. Implement Test Schema function in frontend/backend.
> > > 3. Make the service-center version forward compatible.
> > > 4. Frontend uses proxy to access service-center, this allows the user
> to
> > > access the frontend service without limiting the listening address of
> > > service-center.
> > > 5. Show detailed error message in frontend.
> > >
> > > Java-Chassis 1.0.0-m2
> > > 1. Improve metrics support. (353、359、383、384、385)
> > > 2. Support file/stream transportation to support multi-media
> > > contents(music,pictures). (201)
> > > 3. Support schema/operation level of QPS control. (352)
> > > 4. Support custom handling of messages while marshaling/unmarshaling.
> > (373)
> > > 5. Add "environment" configuration for micro-services. (424)
> > > 6. Add archetypes for java-chassis. (439、440、441、442、470)
> > > 7. Add demo to show how to include java-chassis in gradle. (457)
> > > 8. Improve auto-discovery of service-center instances. (457)
> > > 9. Asynchronous programming model support(AsyncRestTemplate, rxJava
> > > Observable). (444)
> > >
> > > Saga 0.2.0
> > > 1. Load-balance support for omega. (340)
> > > 2. Multiple tenant support. (341)
> > > 3. SSL support for gRPC. (342)
> > > 4. Support dubbo/SpringCloud.
> > > 5. Support sub-transaction retry on failure.
> > >
> > > Release 2 (around 07.30)
> > > Service-Center:
> > >
> > > Java-Chassis:
> > > 1. Support Java9/Java10.
> > > 2. Support generics in highway. (267)
> > >
> > > Saga:
> > > 1. Support Java9/Java10.
> > > 2. Compensation on service instead of on instance. (522)
> > >
> > > --
> > > Best Regards,
> > > Yang.
> > >
> >
>



-- 
Best Regards,
Yang.

[Discuss]Feature list for next releases.

[Yang Bo]

Hi, All:

Below are features that I collected for the next releases. Please check
whether they are correct and supplement ones that's missed.

Please also check whether the version number and release dates are OK.

Release 1 (around 05.30)

Service-Center 1.0.0-m2
1. Supports range delete in registry command.
2. Implement Test Schema function in frontend/backend.
3. Make the service-center version forward compatible.
4. Frontend uses proxy to access service-center, this allows the user to
access the frontend service without limiting the listening address of
service-center.
5. Show detailed error message in frontend.

Java-Chassis 1.0.0-m2
1. Improve metrics support. (353、359、383、384、385)
2. Support file/stream transportation to support multi-media
contents(music,pictures). (201)
3. Support schema/operation level of QPS control. (352)
4. Support custom handling of messages while marshaling/unmarshaling. (373)
5. Add "environment" configuration for micro-services. (424)
6. Add archetypes for java-chassis. (439、440、441、442、470)
7. Add demo to show how to include java-chassis in gradle. (457)
8. Improve auto-discovery of service-center instances. (457)
9. Asynchronous programming model support(AsyncRestTemplate, rxJava
Observable). (444)

Saga 0.2.0
1. Load-balance support for omega. (340)
2. Multiple tenant support. (341)
3. SSL support for gRPC. (342)
4. Support dubbo/SpringCloud.
5. Support sub-transaction retry on failure.

Release 2 (around 07.30)
Service-Center:

Java-Chassis:
1. Support Java9/Java10.
2. Support generics in highway. (267)

Saga:
1. Support Java9/Java10.
2. Compensation on service instead of on instance. (522)

-- 
Best Regards,
Yang.

Re: Ask for Help of ServiceComb Saga

[Yang Bo]

Hi,

 I'll work on the SSL support of gRPC.

[1]https://issues.apache.org/jira/browse/SCB-342

On Mon, Apr 9, 2018 at 6:15 PM, 李波  wrote:

> Hi,
>
> I will take the second issue, add a demo using pack with java chassis
> about *transfering
> money* (*)[1]
>
> [1]  https://issues.apache.org/jira/browse/SCB-244
>
>
> Best Regards!
> Li Bo
>
>
> 2018-04-09 17:54 GMT+08:00 Willem Jiang :
>
> > Hi,
> >
> > There are some small tasks which are easy for the newbee to take to
> > understand better about ServiceComb Saga. Please feel free to take if you
> > like.
> >
> >
> > 1.  secure gPRC transport (*) [1]
> > We need to support SSL transport for gPRC , and also need to verify the
> > Alpha Server's identity
> >
> > 2.  add demo to use pack with java chassis (*) [2]
> > Current we just have some demo of spring boot,  we may need to verify if
> we
> > can interceptor the invocation of java chassis
> >
> > 3. compact events to remove unnecessary fields(*) [3]
> > It can help you know more about the events between the  Omega and Alpha
> >
> > 4. acceptance tests related issue (**) [4][5][6]
> > It can help you know better about the acceptance test, we need to update
> > the demo to let the transaction timeout
> >
> > [1]https://issues.apache.org/jira/browse/SCB-342
> > [2]https://issues.apache.org/jira/browse/SCB-244
> > [3]https://issues.apache.org/jira/browse/SCB-268
> > [4]https://issues.apache.org/jira/browse/SCB-301
> > [5]https://issues.apache.org/jira/browse/SCB-302
> > [6]https://issues.apache.org/jira/browse/SCB-303
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> >   http://jnn.iteye.com  (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
>



-- 
Best Regards,
Yang.

Re: [VOTE] Holding Apache ServiceComb (incubating) Meetup Hosted by Huawei Cloud as a Co-located Event in LC3 2018 Aisa

[Yang Bo]

+1

On Mon, Apr 9, 2018 at 5:55 PM, 李波  wrote:

> +1
>
> Best!
> Li Bo
>
>
> 2018-04-09 13:25 GMT+08:00 Jean-Baptiste Onofré :
>
> > Hi,
> >
> > it sounds good. Unfortunately, I'm not in the area ;)
> >
> > I hope next time ;)
> >
> > Regards
> > JB
> >
> > On 04/08/2018 04:13 PM, Willem Jiang wrote:
> > > +1 （Binding）
> > >
> > >
> > > Willem Jiang
> > >
> > > Blog: http://willemjiang.blogspot.com (English)
> > >   http://jnn.iteye.com  (Chinese)
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sun, Apr 8, 2018 at 3:40 PM, Zen Lin 
> > wrote:
> > >
> > >> Hi All,
> > >> This is a call for Vote to hold Apache ServiceComb (incubating) Meetup
> > >> Hosted by Huawei Cloud as a Co-located Event in LC3 2018 Aisa.
> > >>
> > >> As discussed in the meetup propersal[1], we have plan to hold Apache
> > >> ServiceComb (incubating) Mini Meetup, details are listed bellow,
> > >>
> > >>
> > >>- What is the topic focus of the event?
> > >>
> > >> Topics are focused on user-pratices/technologies/ecosystem of Apache
> > >> ServiceComb (incubating)
> > >>
> > >>- Who is organising the event?
> > >>
> > >> PMCs of ServiceComb (incubating) are the organizer
> > >>
> > >>- When is the event?
> > >>
> > >>  one day Between Jun 25, 2018 and Jun 27, 2018, maybe in Jun 26, 2018
> > >>
> > >>- How many attendees are expected?
> > >>
> > >> 60~100
> > >>
> > >>- How much PMC involvement is there already?
> > >>
> > >> 5
> > >>
> > >>- Which marks are requested?
> > >>
> > >> Two marks are requested,
> > >> 1. Name of "Apache ServiceComb Incubating Meetup Hosted by Huawei
> Cloud"
> > >> 2. "Powered By" Apache Incubator logo of Apache ServiceComb
> (incubating)
> > >>
> > >>- Is this for profit or non-profit? (See "Event Profits And
> > Donations")?
> > >>
> > >> non-profit.
> > >>
> > >>
> > >>
> > >> [1]  https://www.mail-archive.com/dev@servicecomb.apache.org/
> > msg03298.html
> > >>
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>



-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Saga (incubating) version 0.1.0 - Second Attempt

[Yang Bo]

+1

Checks I've done:

1. Checked sha512sum and GPG signature.

2. Run rat without filter on source and binary package.

3. Checked DISCLAIMER/NOTICE/LICENSE for source and binary package.

4. Checked that no unlicensed binary files are bundled in source and binary
package.

5. Build from source following README.md

6. Run simple application following the booking demo.



On Sat, Mar 17, 2018 at 3:01 AM, Mohammad Asif Siddiqui <
asifdxtr...@apache.org> wrote:

> Hi All,
>
> This is a call for Vote to release Apache ServiceComb Saga (Incubating)
> version 0.1.0
>
> Release Notes : https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12321626&version=12342353
>
> Release Candidate : https://dist.apache.org/repos/dist/dev/incubator/
> servicecomb/incubator-servicecomb-saga/0.1.0/
>
> Staging Repo : https://repository.apache.org/content/repositories/
> orgapacheservicecomb-1166
>
> Release Tag : https://github.com/apache/incubator-servicecomb-saga/
> releases/tag/0.1.0
>
> Release CommitID : 708eec092988dfd4a5960ca5f232fb7421d5fbdd
>
> Keys to verify the Release Candidate : https://dist.apache.org/repos/
> dist/dev/incubator/servicecomb/KEYS
>
> Voting will start now ( Saturday, 17th March, 2018) and will remain open
> for next 72 hours, Request all PPMC members to give their vote
>
> [ ] +1 Release this package as 0.1.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> Regards
> Asif
>
>


-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Java-Chassis (incubating) version 1.0.0-m1 - Second Attempt

[Yang Bo]

 +1


Checks I've done:

1. Run rat without any filters.

2. Checked no images files(*.jpg,*.png) and font files (*.ttf) are included
without permission in source and binary packages.

3. Checked that no JS files distributed in Java Chassis.

4. Checked LICENSE/NOTICE/DISCLAIMER for source and binary packages.
5. Run integration tests and bmi sample.

On Sat, Mar 17, 2018 at 2:52 AM, Mohammad Asif Siddiqui <
asifdxtr...@apache.org> wrote:

> Hi All,
>
> This is a call for Vote to release Apache ServiceComb Java-Chassis
> (Incubating) version 1.0.0-m1
>
> Release Notes : https://github.com/apache/incubator-servicecomb-java-
> chassis/blob/master/etc/releaseNotes.md
>
> Release Candidate : https://dist.apache.org/repos/dist/dev/incubator/
> servicecomb/incubator-servicecomb-java-chassis/1.0.0-m1/
>
> Staging Repo : https://repository.apache.org/content/repositories/
> orgapacheservicecomb-1181/
>
> Release Tag : https://github.com/apache/incubator-servicecomb-java-
> chassis/releases/tag/1.0.0-m1
>
> Release CommitID : 3dbfb87eb6249f3ad41ea7514d1a73ec6e193bfe
>
> Keys to verify the Release Candidate : https://dist.apache.org/repos/
> dist/dev/incubator/servicecomb/KEYS
>
> Voting will start now ( Saturday, 17th March, 2018) and will remain open
> for next 72 hours, Request all PPMC members to give their vote
>
> [ ] +1 Release this package as 1.0.0-m1
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> Regards
> Asif
>
>


-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Service-Center (incubating) version 1.0.0-m1 - Fourth Attempt

[Yang Bo]

+1

1. Checked the binary and source releases' sha512sum and gpg signature.

2. Checked LICENSE/DISCLAIMER/NOTICE of binary and source release.

3. Run rat on binary and source release, some minor issues found.

4. Building from source following the README

5. Running service center and frontend according to README

6. Run service-center and frontend on windows, checked basic functionality
of frontend.

7. Run service-center and frontend on linux, run BMI sample of Java Chassis
using service-center, checked basic functionality of frontend.

8. Checked both binary and source files, no inappropriate binary files
bundled(images, fonts).


On Sat, Mar 17, 2018 at 2:38 AM, Mohammad Asif Siddiqui <
asifdxtr...@apache.org> wrote:

> Hi All,
>
> This is a call for Vote to release Apache ServiceComb Service-Center
> (Incubating) version 1.0.0-m1 (fourth release candidate).
>
> Release Notes : https://github.com/apache/incubator-servicecomb-service-
> center/blob/master/docs/release/releaseNotes.md
>
> Release Candidate : https://dist.apache.org/repos/dist/dev/incubator/
> servicecomb/incubator-servicecomb-service-center/1.0.0-m1/
>
> Release Tag : https://github.com/apache/incubator-servicecomb-service-
> center/releases/tag/1.0.0-m1
>
> Release CommitID : 94cea25ba55e763dbe23d0cd4a8da73e37a50539
>
> Keys to verify the Release Candidate : https://dist.apache.org/repos/
> dist/dev/incubator/servicecomb/KEYS
>
> Guide to build the release from source : https://github.com/apache/
> incubator-servicecomb-service-center/tree/master/scripts/release
>
> Voting will start now ( Saturday, 17th March, 2018) and will remain open
> for next 72 hours, Request all PPMC members to give their vote.
> [ ] +1 Release this package as 1.0.0-m1
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> Regards
> Asif
>
>
>


-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Service-Center (incubating) version 1.0.0-m1

[Yang Bo]

Hi Asif,

For the first issue, It's OK that we leave it as is in this release. But in
the long run, it's still better to put the configurations together(the
frontend.conf file).


On Thu, Mar 8, 2018 at 3:31 PM, Mohammad Asif Siddiqui <
asifdxtr...@apache.org> wrote:

> Hi YangBo,
>
> Thanks for your vote.
>
> We will fix the 2nd and 3rd Issue.
>
> For 1st Issue I would like to clear that the hardcode values are in js
> files which can be modifies easily afterwards in the release, which we have
> already mentioned in our Readme over here [1]
>
> [1] https://github.com/apache/incubator-servicecomb-service-
> center/tree/master/frontend#note
>
> Regards
> Asif
>
>
> On 2018/03/08 07:20:17, Yang Bo  wrote:
> > -1 Binding Vote.
> >
> > Below Checks Done:
> > 1. Verified the md5sum, sha1sum and GPG signature for source and binary
> > release packages.
> > 2. Verified the service-center linux release using Java Chassis BMI
> sample.
> > 3. Verified the frontend on both windows and linux.
> > 4. Checked the bundled files, no fonts and images without proper
> licensing
> > bundled.
> > 5. Checked the LICENSE/NOTICE, README, DISCLAIMER for both binary and
> > source release
> > 6. RAT on source release is OK
> >
> > Some issues:
> > 1. The service-center's address/port is hardcoded in frontend's js file,
> > which cause the frontend to not functioning if service center is not
> > running on 127.0.0.1:30100.
> > Bug report: https://issues.apache.org/jira/browse/SCB-375
> >
> > 2. The scripts in binary release does not contain the ASF header.
> > start-frontend.sh
> > start-service-center.sh
> > stop-frontend.sh
> > stop-service-center.sh
> >
> > 3. Scripts on source release have ASF header but the script shebang is
> not
> > in the first line, which would cause problems if the script is not called
> > directy by bash. We should still put the shell shebang on the first line
> of
> > scripts and followd by a blank line then the ASF header.
> > For example:
> > ===
> > #!/bin/bash
> >
> > # Licensed to the Apache ...
> >
> >
> > On Thu, Mar 8, 2018 at 2:15 PM, Sukesh A C  wrote:
> >
> > > +1 Binding Vote.
> > >
> > > Below Checks Done:
> > > 1. Verify the file signature.
> > > 2. Verified windows release for service center using java chassis demo.
> > > 3. Ran the Service-Center and Frontend, verified basic functionality of
> > > service center and frontend.
> > >
> > > Thanks,
> > > Sukesh.
> > >
> > > -Original Message-
> > > From: Mohammad Asif Siddiqui [mailto:asifdxtr...@apache.org]
> > > Sent: 07 March 2018 23:11
> > > To: dev@servicecomb.apache.org
> > > Subject: [VOTE] Release Apache ServiceComb Service-Center (incubating)
> > > version 1.0.0-m1
> > >
> > > Hi All,
> > >
> > > This is a call for Vote to release Apache ServiceComb Service-Center
> > > (Incubating) version 1.0.0-m1 (second release candidate).
> > >
> > > Release Notes : https://github.com/apache/
> incubator-servicecomb-service-
> > > center/blob/master/docs/release/releaseNotes.md
> > >
> > > Release Candidate : https://dist.apache.org/repos/dist/dev/incubator/
> > > servicecomb/incubator-servicecomb-service-center/1.0.0-m1/
> > >
> > > Release Tag : https://github.com/apache/incubator-servicecomb-service-
> > > center/releases/tag/1.0.0-m1
> > >
> > > Release CommitID : cb48d5b1a84bfae3b111a34955664e30cb4b9f3f
> > >
> > > Keys to verify the Release Candidate : https://dist.apache.org/repos/
> > > dist/dev/incubator/servicecomb/KEYS
> > >
> > > Release Source : https://dist.apache.org/repos/dist/dev/incubator/
> > > servicecomb/incubator-servicecomb-service-center/1.0.0-m1/src/
> > >
> > > Guide to build the release from source : https://github.com/apache/
> > > incubator-servicecomb-service-center/tree/master/scripts/release
> > >
> > > Voting will start now ( Wednesday, 7th March, 2018) and will remain
> open
> > > for next 72 hours, Request all PPMC members to give their vote.
> > >
> > > [ ] +1 Release this package as 1.0.0-m1.
> > > [ ] +0 No Opinion.
> > > [ ] -1 Do not release this package because
> > >
> > > Regards
> > > Asif
> > >
> > >
> > >
> >
> >
> > --
> > Best Regards,
> > Yang.
> >
>



-- 
Best Regards,
Yang.

Re: [VOTE] Release Apache ServiceComb Service-Center (incubating) version 1.0.0-m1

[Yang Bo]

-1 Binding Vote.

Below Checks Done:
1. Verified the md5sum, sha1sum and GPG signature for source and binary
release packages.
2. Verified the service-center linux release using Java Chassis BMI sample.
3. Verified the frontend on both windows and linux.
4. Checked the bundled files, no fonts and images without proper licensing
bundled.
5. Checked the LICENSE/NOTICE, README, DISCLAIMER for both binary and
source release
6. RAT on source release is OK

Some issues:
1. The service-center's address/port is hardcoded in frontend's js file,
which cause the frontend to not functioning if service center is not
running on 127.0.0.1:30100.
Bug report: https://issues.apache.org/jira/browse/SCB-375

2. The scripts in binary release does not contain the ASF header.
start-frontend.sh
start-service-center.sh
stop-frontend.sh
stop-service-center.sh

3. Scripts on source release have ASF header but the script shebang is not
in the first line, which would cause problems if the script is not called
directy by bash. We should still put the shell shebang on the first line of
scripts and followd by a blank line then the ASF header.
For example:
===
#!/bin/bash

# Licensed to the Apache ...


On Thu, Mar 8, 2018 at 2:15 PM, Sukesh A C  wrote:

> +1 Binding Vote.
>
> Below Checks Done:
> 1. Verify the file signature.
> 2. Verified windows release for service center using java chassis demo.
> 3. Ran the Service-Center and Frontend, verified basic functionality of
> service center and frontend.
>
> Thanks,
> Sukesh.
>
> -Original Message-
> From: Mohammad Asif Siddiqui [mailto:asifdxtr...@apache.org]
> Sent: 07 March 2018 23:11
> To: dev@servicecomb.apache.org
> Subject: [VOTE] Release Apache ServiceComb Service-Center (incubating)
> version 1.0.0-m1
>
> Hi All,
>
> This is a call for Vote to release Apache ServiceComb Service-Center
> (Incubating) version 1.0.0-m1 (second release candidate).
>
> Release Notes : https://github.com/apache/incubator-servicecomb-service-
> center/blob/master/docs/release/releaseNotes.md
>
> Release Candidate : https://dist.apache.org/repos/dist/dev/incubator/
> servicecomb/incubator-servicecomb-service-center/1.0.0-m1/
>
> Release Tag : https://github.com/apache/incubator-servicecomb-service-
> center/releases/tag/1.0.0-m1
>
> Release CommitID : cb48d5b1a84bfae3b111a34955664e30cb4b9f3f
>
> Keys to verify the Release Candidate : https://dist.apache.org/repos/
> dist/dev/incubator/servicecomb/KEYS
>
> Release Source : https://dist.apache.org/repos/dist/dev/incubator/
> servicecomb/incubator-servicecomb-service-center/1.0.0-m1/src/
>
> Guide to build the release from source : https://github.com/apache/
> incubator-servicecomb-service-center/tree/master/scripts/release
>
> Voting will start now ( Wednesday, 7th March, 2018) and will remain open
> for next 72 hours, Request all PPMC members to give their vote.
>
> [ ] +1 Release this package as 1.0.0-m1.
> [ ] +0 No Opinion.
> [ ] -1 Do not release this package because
>
> Regards
> Asif
>
>
>


-- 
Best Regards,
Yang.

Re: Clean up the old saga modules

[Yang Bo]

Seems everyone is OK with deleting the legacy code.
I'll include those changes as part of the m1 release.

On Mon, Feb 26, 2018 at 8:08 PM, Willem Jiang 
wrote:

> I think it depends on the user requirement.
> we can keep the old code there, if the user want to use it , we can put it
> back.
>
> On 2/26/18, Zheng Feng  wrote:
> > It looks good. Do we want to support the old saga module in the future ?
> >
> > 2018-02-24 16:47 GMT+08:00 Willem Jiang :
> >
> >> Hi team,
> >>
> >> As we are planning the servicecomb-saga binary release[1], I found out
> >> there are some old saga modules in the current master branch need to be
> >> archived.
> >>
> >> My proposal is we create a branch which holds current master branch
> codes
> >> and remove the old saga module from the master branch. After that, we
> >> just
> >> put the pack modules into the binary release of servicecomb-saga.
> >>
> >> Any thoughts？
> >>
> >> [1] https://issues.apache.org/jira/browse/SCB-346
> >>
> >> Willem Jiang
> >>
> >> Blog: http://willemjiang.blogspot.com (English)
> >>   http://jnn.iteye.com  (Chinese)
> >> Twitter: willemjiang
> >> Weibo: 姜宁willem
> >>
> >
>
>
> --
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>



-- 
Best Regards,
Yang.

Re: [Please Review]New features and changes since 0.5.0 for Java Chassis

[Yang Bo]

Hi,

Below is the propsed release notes for Java Chassis m1. Please check.

--

Major improvements:

Java Chassis can now use Apollo as configuration center. Users can now
change configurations like load balancing policy and those changes will
come into effect on the fly.
See http://servicecomb.incubator.apache.org/users/dynamic-config/ for more
details.

Metrics was re-factored. We now uses events for collecting invocation data
instead of Hystrix. This reduces the performance penalty of computing
metrics.
Metrics can now be fetched via '/metrics' using HTTP.
See http://servicecomb.incubator.apache.org/users/metrics-in-1.0.0-m1/ for
more details.

Other Noticeable Changes:

  - The Java Chassis libraries are now under group "org.apache.servicecomb".
  - We provide out of the box metrics support now. Prometheus and Overwatch
is supported.
  - Configuration center was re-factored and moved out from foundation.
Support for Apollo was added.
  - Users can now use Object type for calling services.
  - Users can now use Generics for calling services.
  - Better integration with Spring MVC.
  - Upgraded to zipkin2 internally, Java Chassis can now work with zipkin
server v1 and v2.
  - We are in the process of supporting reactive programming. Pojo consumer
and provider now supports CompletableFutre.

On Mon, Jan 29, 2018 at 4:13 PM, Eric Lee  wrote:

> Hi all,
> The release notes for Saga 0.1.0 is as follows. Please check if there is
> anything missing, thanks.
>
> Saga 0.0.1 relied heavily on the coordinator to forward requests which
> needs users to specify their work flow explicitly as json requests.
>
> Saga 0.1.0 uses a new architecture pack which is inspired by Zipkin.
> Transactions are connected by global id and identified by unique local id.
> In pack, alpha plays as the coordinator while omega plays as the sidecar.
>
> Implemented changes:
>
>-
>
>Omega supports to intercept ingoing/outgoing HTTP requests and inject
>transaction ids into request headers
>-
>
>Omega supports to customize compensation method by annotation
>-
>
>Omega supports to customize starting point of the whole transaction
>-
>
>Sub transactions can link as a single global transaction
>-
>
>Omega supports to serialize/deserialize by Kryo
>-
>
>Alpha supports to store transaction events permanently
>-
>
>Alpha is able to talk to omega through gRPC
>-
>
>Alpha becomes stateless to simplify alpha recovery
>    -
>
>Acceptance tests(success, fail but compensate successfully) for the
>usage demo
>
>
>
> 2018-01-29 15:05 GMT+08:00 Yang Bo :
>
> > Hi all,
> >
> > We'are preparing the release notes for Java Chassis 1.0.0.m1, the
> following
> > is a list of changes and features since 0.5.0. Please check whether they
> > are correct and supplement anything missing, thanks.
> >
> >   - The Java Chassis libraries are now under group
> > "org.apache.servicecomb".
> >   - We provide out of the box metrics support now. Prometheus and
> Overwatch
> > is supported.
> >   - Configuration center was re-factored and moved out from foundation.
> > Support for Apollo was added.
> >   - Users can now use Object type for calling services.
> >   - Users can now use Generics for calling services.
> >   - Better integration with Spring MVC.
> >   - Upgraded to zipkin2 internally, Java Chassis can now work with zipkin
> > server v1 and v2.
> >   - We are in the process of supporting reactive programming. Pojo
> consumer
> > and provider now supports CompletableFutre.
> >
> >
> > --
> > Best Regards,
> > Yang.
> >
>



-- 
Best Regards,
Yang.

[TO ALL, Please read] Issues regarding commit messages and PR messages

[Yang Bo]

Hi,

I've been preparing the release notes for Servicecomb lately, and I have
found the following problems:

1. The commit messages are not clear
  The commit messages should have a concise and clear headline describing
what the commit changed followed by a detailed body explaining why and how,
and other necessary information. Most of the commit messages are unclear
and does not have a body.
  Please read this article for how to write a commit message:
https://chris.beams.io/posts/git-commit/

2. The PR messages are not clear
  There is a rule in checklist for the PR states 'Each commit in the pull
request should have a meaningful subject line and body'. But few of us
followed.
  For simple changes, the commit message is enough to be used as PR
message. For more complicated changes, we should provide more information.

3. The issues in the Jira system are not clear.

4. The issue tags are not correctly used in jira.
   Changes that introduce new functionality can be tagged as feature.
   Changes only affect internal API should be marked as improvement.

   For tasks, we should also mark it as one of the following:
feature/improvement/bugfix.


Clear commit messages and PR messages is a critical part of an open-source
project. Because only with a clear history log, new developers can get the
information they are interested in without repeated direct communication
with us.



-- 
Best Regards,
Yang.

[Please Review]New features and changes since 0.5.0 for Java Chassis

[Yang Bo]

Hi all,

We'are preparing the release notes for Java Chassis 1.0.0.m1, the following
is a list of changes and features since 0.5.0. Please check whether they
are correct and supplement anything missing, thanks.

  - The Java Chassis libraries are now under group "org.apache.servicecomb".
  - We provide out of the box metrics support now. Prometheus and Overwatch
is supported.
  - Configuration center was re-factored and moved out from foundation.
Support for Apollo was added.
  - Users can now use Object type for calling services.
  - Users can now use Generics for calling services.
  - Better integration with Spring MVC.
  - Upgraded to zipkin2 internally, Java Chassis can now work with zipkin
server v1 and v2.
  - We are in the process of supporting reactive programming. Pojo consumer
and provider now supports CompletableFutre.


-- 
Best Regards,
Yang.

Re: [Discussion] How to make sure events are handled only once amongdifferent stateless Saga pack alphas

[Yang Bo]

Hi,

Using the database as the locking mechanism may have performance issues. We
will need to lock the whole table for picking a new task to begin.

We will need a way to synchronize the jobs' status
1. Use a master-worker model. The master communicate with the database and
dispatch jobs to the workers. This model is simple to understand and
implement. But it may face performance issues in the master node. There are
a lot of communication between the master and workers. And when the number
of tasks is large, the syncrhonization between the workers and master will
block and affect the whole system's performance.

2. Use a third-parties for distributed locking, like etcd or redis. As we
use a sql database for storing data already, redis may works better for us.
Or we can just use etcd to replace the sql database.

3. Implement a distributed lock. Seems an overkill.


On Sun, Jan 28, 2018 at 10:52 AM, Eric Lee  wrote:

> I guess we can add a status column in the timeout table. It has three
> types: NEW, PENDING, DONE. When event starts, the status turns NEW. When
> the EventScanner detects the timeout event, it sets the status to PENDING.
> When another EventScanner scans the same timeout event, if it can not
> update its status to PENDING, it will skip this event.
>
> 2018-01-28 9:51 GMT+08:00 Willem Jiang :
>
> > Yeah, this could help us resolve the issue that different alpha server
> > check the same TxEvent.
> > But what if some of the alpha is offline,  the timeout message cannot be
> > handled any more.
> > Maybe we can create a leader from the alpha server to do job assign work,
> > and supervise the timeout event.
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> >   http://jnn.iteye.com  (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, Jan 27, 2018 at 11:53 PM, Zheng Feng  wrote:
> >
> > > The different alpha server I assumes that it has the different name, So
> > we
> > > can insert the name of the alpha server in the TxEvent record.
> > > When the alpha server is scanning the TxEvent records for the time out
> > > handling, it could only select these ones match the alpha name.
> > > It looks like that we don't need the lock here and it has to make sure
> > the
> > > alpha server name is unique.
> > >
> > > 2018-01-27 14:36 GMT+08:00 郑扬勇 :
> > >
> > > > It seems all solution need import "lock";
> > > >  If one event can only handle by one alpha at the same time,we may
> need
> > > > election mechanism ?
> > > >
> > > >   -- 原始邮件 --
> > > >   发件人: "Eric Lee";;
> > > >  发送时间: 2018年1月26日(星期五) 上午10:58
> > > >  收件人: "dev";
> > > >
> > > >  主题: [Discussion] How to make sure events are handled only once
> > > > amongdifferent stateless Saga pack alphas
> > > >
> > > >
> > > >
> > > > Background
> > > > Currently, the transaction timeout is controlled by omega which makes
> > > omega
> > > > stateful. Being stateful makes omega recovery relies greatly on the
> > > > previous states. Hence, we need to move the timeout management from
> > omega
> > > > to alpha to simplify implementation of omega. After that, omega will
> > be a
> > > > stateless agent.
> > > >
> > > > Difficulty
> > > > How to make sure each timeout record are handled only once globally
> by
> > > > multiple alpha servers? Each alpha server is also stateless. All
> states
> > > are
> > > > stored in database. Alpha will scan the timeout events and handles
> them
> > > one
> > > > by one periodically. Different alpha may process the same event at
> the
> > > same
> > > > time which should be avoided because each event should be handled
> only
> > > > once.
> > > >
> > > > Possible Solutions:
> > > > 1. Add a expireTime column in TxEvent entity. Then lock the access to
> > the
> > > > timeout event to avoid concurrent access to the same event. Since
> > TxEvent
> > > > may involves many operations, adding the lock may introduce latency
> in
> > > > other transaction.
> > > > 2. Create a new entity like the Command entity. Then lock the access
> to
> > > > this entity and update the status asynchronously when it is done.
> > > > 3. Register timeout settings to alpha whenever omega starts. Then
> query
> > > > TxEvent and ServiceConfig table to find out timeout events. This way
> > > still
> > > > can not make sure each event is handled once as the range of the lock
> > is
> > > > too wide to target at a specific event.
> > > >
> > > > However, the above solutions still not perfect for the problem
> because
> > > the
> > > > lock will become invalid as soon as the query is done and another
> alpha
> > > may
> > > > query from database and process the same event before the timeout
> event
> > > > being processed by the previous alpha.
> > > >
> > > > Current implementation details can move forward to
> > > > https://github.com/apache/incubator-servicecomb-saga/pull/122 .
> > > >
> > > > Any suggestion is welcome.
> > > >
> > > >
> > > > Best Regards!
> 

[Discussion] Release Candidate or service-center m1 package

[Yang Bo]

Hi Asif,

Thanks for preparting the service-center m1 release package. I just checked
and found the following problems:

1. The package does not contain the README, NOTICE, DISCLAIMER and LICENSE
files required by ASF policy.
2. The frontend is not packged.

Do you have a script for generating the package? If so, could you please
commit it to the main repo.

I'll do some basic functionality test and report the test results later
today.

-- 
Best Regards,
Yang.

Re: Prepare to cut the 1.0.0-m1 Release this week

[Yang Bo]

Hi,

The NOTICE file have been added for Sagan and Service Center, please check
the PR.

On Mon, Jan 22, 2018 at 2:58 PM, Willem Jiang 
wrote:

> Hi LiBo,
>
> As the Configuration support of Apollo and Configuration Center are quite
> similar, it doesn't make sense that we put these two module into different
> places and have  different configuration codes.
>
> Please file a JIRA for it and start the discussion for it.
>
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jan 22, 2018 at 12:55 PM, 李波  wrote:
>
> > Dear all,
> >
> > There are two things left for dynamic configuration center:
> > 1.  Configuration item cse.config.client.serverUri in microservice.yaml
> is
> > still in need even using Apollo as configuration center.
> > I'm thinking it's a bad configuration for users while we have
> > apollo.config.serverUri.  It's necessary because there is a check
> condition
> > of cse.config.client.serverUri to decide whether to use configuration
> > center in previous code.
> >
> > Anybody know how to solve this problem elegantly.
> >
> > 2. As Chassis have root module named dynamic-config, we should transfer
> > foundation-config-cc module to dynamic-config too.
> >
> > Best Regards!
> > LiBo
> >
> > 2018-01-22 9:26 GMT+08:00 Willem Jiang :
> >
> > > Hi Team，
> > >
> > > As we plan to do the release at end of this month. It's time to do some
> > > preparation now.
> > > Current we just updated the NOTIC file of the java chassis project,  we
> > > should do the same thing on saga and service center projects.
> > >
> > > Please let me if there are some important features need to be finished
> > this
> > > week.
> > >
> > >
> > > Willem Jiang
> > >
> > > Blog: http://willemjiang.blogspot.com (English)
> > >   http://jnn.iteye.com  (Chinese)
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> >
>

Re: [Discussion]Third party license issue in Saga

[Yang Bo]

Hi Sean Yin,

Your fix worked, thank you.

On Mon, Jan 22, 2018 at 11:10 AM, Sean Yin  wrote:

> Hi Yang Bo,
>
> We can just exclude them from our project. I will do it.
>
> On Mon, Jan 22, 2018 at 10:09 AM, Yang Bo  wrote:
>
> > Hi,
> >
> > I'm preparing the NOTICE file for saga 1.0 release and I'm having the
> > following problems:
> >
> > 1. The Saga project depends on Java Chassis project which includes
> >  FindBugs-Annotations (http://findbugs.sourceforge.net/)
> > com.google.code.findbugs:annotations:jar:2.0.0
> > which is under LGPL. We have fixed this in the Java Chassis project, but
> > it's group is changed to 'servicecomb.apache.org'. But the Saga project
> > still uses the 'io.servicecom' group.
> >
> > Shall we release Saga after Java Chassis? Or is it OK that we release
> Saga
> > first knowing that the dependency on findbugs:annotations will be removed
> > later?
> >
> > 2. The Saga project includes the json library which is under the JSON
> > license.
> >
> > The json library is imported by hamcrest-json and
> spring-boot-starter-test,
> > maybe we can exclude the dependency in the pom?
> >
> > org.json:json:jar:20090211
> > org.json:json:jar:20140107
> > ---
> > [INFO] +- com.github.seanyinx:unit-scaffolding:jar:1.0.0:test
> > [INFO] \- uk.co.datumedge:hamcrest-json:jar:0.2:test
> > [INFO]\- org.skyscreamer:jsonassert:jar:1.1.1:test
> > [INFO]   +- org.json:json:jar:20090211:test
> >
> > [INFO] +-
> > org.springframework.boot:spring-boot-starter-test:jar:1.4.5.RELEASE:test
> > [INFO] |  +-
> > org.springframework.boot:spring-boot-test:jar:1.4.5.RELEASE:test
> > [INFO] |  +-
> > org.springframework.boot:spring-boot-test-autoconfigure:jar:1.4.5.
> > RELEASE:test
> > [INFO] |  +- com.jayway.jsonpath:json-path:jar:2.2.0:test
> > [INFO] |  |  \- net.minidev:json-smart:jar:2.2.1:test
> > [INFO] |  | \- net.minidev:accessors-smart:jar:1.1:test
> > [INFO] |  |\- org.ow2.asm:asm:jar:5.0.3:test
> > [INFO] |  +- org.assertj:assertj-core:jar:2.5.0:test
> > [INFO] |  +- org.hamcrest:hamcrest-core:jar:1.3:test
> > [INFO] |  +- org.hamcrest:hamcrest-library:jar:1.3:test
> > [INFO] |  +- org.skyscreamer:jsonassert:jar:1.3.0:test
> > [INFO] |  |  \- org.json:json:jar:20140107:test
> >
> >
> > [INFO] | +-
> > org.springframework.boot:spring-boot-starter-test:jar:
> > 1.4.5.RELEASE:compile
> > [INFO] |  +-
> > org.springframework.boot:spring-boot-test:jar:1.4.5.RELEASE:compile
> > [INFO] |  +-
> > org.springframework.boot:spring-boot-test-autoconfigure:jar:1.4.5.
> > RELEASE:compile
> > [INFO] |  +- com.jayway.jsonpath:json-path:jar:2.2.0:compile
> > [INFO] |  |  \- net.minidev:json-smart:jar:2.2.1:compile
> > [INFO] |  | \- net.minidev:accessors-smart:jar:1.1:compile
> > [INFO] |  |\- org.ow2.asm:asm:jar:5.0.3:compile
> > [INFO] |  +- org.assertj:assertj-core:jar:2.5.0:compile
> > [INFO] |  +- org.mockito:mockito-core:jar:1.10.19:test
> > [INFO] |  |  \- org.objenesis:objenesis:jar:2.1:test
> > [INFO] |  +- org.hamcrest:hamcrest-core:jar:1.3:test
> > [INFO] |  +- org.hamcrest:hamcrest-library:jar:1.3:compile
> > [INFO] |  +- org.skyscreamer:jsonassert:jar:1.3.0:compile
> > [INFO] |  |  \- org.json:json:jar:20140107:compile
> > ---
> >
>

[Discussion]Third party license issue in Saga

[Yang Bo]

Hi,

I'm preparing the NOTICE file for saga 1.0 release and I'm having the
following problems:

1. The Saga project depends on Java Chassis project which includes
 FindBugs-Annotations (http://findbugs.sourceforge.net/)
com.google.code.findbugs:annotations:jar:2.0.0
which is under LGPL. We have fixed this in the Java Chassis project, but
it's group is changed to 'servicecomb.apache.org'. But the Saga project
still uses the 'io.servicecom' group.

Shall we release Saga after Java Chassis? Or is it OK that we release Saga
first knowing that the dependency on findbugs:annotations will be removed
later?

2. The Saga project includes the json library which is under the JSON
license.

The json library is imported by hamcrest-json and spring-boot-starter-test,
maybe we can exclude the dependency in the pom?

org.json:json:jar:20090211
org.json:json:jar:20140107
---
[INFO] +- com.github.seanyinx:unit-scaffolding:jar:1.0.0:test
[INFO] \- uk.co.datumedge:hamcrest-json:jar:0.2:test
[INFO]\- org.skyscreamer:jsonassert:jar:1.1.1:test
[INFO]   +- org.json:json:jar:20090211:test

[INFO] +-
org.springframework.boot:spring-boot-starter-test:jar:1.4.5.RELEASE:test
[INFO] |  +-
org.springframework.boot:spring-boot-test:jar:1.4.5.RELEASE:test
[INFO] |  +-
org.springframework.boot:spring-boot-test-autoconfigure:jar:1.4.5.RELEASE:test
[INFO] |  +- com.jayway.jsonpath:json-path:jar:2.2.0:test
[INFO] |  |  \- net.minidev:json-smart:jar:2.2.1:test
[INFO] |  | \- net.minidev:accessors-smart:jar:1.1:test
[INFO] |  |\- org.ow2.asm:asm:jar:5.0.3:test
[INFO] |  +- org.assertj:assertj-core:jar:2.5.0:test
[INFO] |  +- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] |  +- org.hamcrest:hamcrest-library:jar:1.3:test
[INFO] |  +- org.skyscreamer:jsonassert:jar:1.3.0:test
[INFO] |  |  \- org.json:json:jar:20140107:test


[INFO] | +-
org.springframework.boot:spring-boot-starter-test:jar:1.4.5.RELEASE:compile
[INFO] |  +-
org.springframework.boot:spring-boot-test:jar:1.4.5.RELEASE:compile
[INFO] |  +-
org.springframework.boot:spring-boot-test-autoconfigure:jar:1.4.5.RELEASE:compile
[INFO] |  +- com.jayway.jsonpath:json-path:jar:2.2.0:compile
[INFO] |  |  \- net.minidev:json-smart:jar:2.2.1:compile
[INFO] |  | \- net.minidev:accessors-smart:jar:1.1:compile
[INFO] |  |\- org.ow2.asm:asm:jar:5.0.3:compile
[INFO] |  +- org.assertj:assertj-core:jar:2.5.0:compile
[INFO] |  +- org.mockito:mockito-core:jar:1.10.19:test
[INFO] |  |  \- org.objenesis:objenesis:jar:2.1:test
[INFO] |  +- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] |  +- org.hamcrest:hamcrest-library:jar:1.3:compile
[INFO] |  +- org.skyscreamer:jsonassert:jar:1.3.0:compile
[INFO] |  |  \- org.json:json:jar:20140107:compile
---