Re: About introduce Lombok to service comb
OK, I think we already got enough feedback here. We won't use the Lombok in ServiceComb-Java-Chassis and for the ServiceComb-Saga we can revisit it later. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Aug 27, 2018 at 2:51 PM yhs0092 wrote: > Agree to Yang Bo, too. > ServiceComb is not a common business project, it's a framework. So there > are not so many Java bean classes defined in it, which means we will not > take so much advantage of Lombok. > While using Lombok requires plug-in installed in IDE, the threshold of > developing and contributing to ServiceComb-Java-Chassis seems to be raised > more or less. > > > Yours sincerely > > > YaoHaishi > yhs0...@163.com > On 8/27/2018 14:16，wjm wjm wrote： > agree to Yang BO. > > 2018-08-27 11:14 GMT+08:00 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
Re: About introduce Lombok to service comb
Agree to Yang Bo, too. ServiceComb is not a common business project, it's a framework. So there are not so many Java bean classes defined in it, which means we will not take so much advantage of Lombok. While using Lombok requires plug-in installed in IDE, the threshold of developing and contributing to ServiceComb-Java-Chassis seems to be raised more or less. Yours sincerely YaoHaishi yhs0...@163.com On 8/27/2018 14:16，wjm wjm wrote： agree to Yang BO. 2018-08-27 11:14 GMT+08:00 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 https://projectlombok.org < https://projectlombok.org/ any thought? -- Best Regards, Yang.
Re: [DISCUSS]Add Vendor Sources Code In SC project
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: About introduce Lombok to service comb
agree to Yang BO. 2018-08-27 11:14 GMT+08:00 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
