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 <[email protected]> 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 > [email protected] > On 8/27/2018 14:16，wjm wjm<[email protected]> wrote： > agree to Yang BO. > > 2018-08-27 11:14 GMT+08:00 Yang Bo <[email protected]>: > > 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 <[email protected]> > 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 赵俊 <[email protected]> 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. > > <dependency> > <groupId>org.projectlombok</groupId> > <artifactId>lombok</artifactId> > <version>1.16.4</version> > <scope>provided</scope> > </dependency> > > > > On 25 Aug 2018, at 9:27 AM, bismy <[email protected]> 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. > > > ------------------ 原始邮件 ------------------ > 发件人: "赵俊"<[email protected]>; > 发送时间: 2018年8月23日(星期四) 上午10:39 > 收件人: "[email protected]"<[email protected]>; > > 主题: 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 <[email protected]> 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"<[email protected]>; > 发送时间: 2018年8月22日(星期三) 下午3:40 > 收件人: "dev"<[email protected]>; > > 主题: 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 <[email protected]> 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 <[email protected]>: > > It looks good to me and the lombok supports the JDK 9 ? > > 2018-08-22 12:21 GMT+08:00 赵俊 <[email protected]>: > > 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 <[email protected]> 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 <[email protected] > : > > 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 saga project, it's up to > java-chassis > to > check > if it want to use it. > > @Team Any thought? > > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Aug 21, 2018 at 12:58 PM, cherrylzhao < > [email protected] > > wrote: > > Hi, all > > Lombok can simplify our work for creating java entity. > Using Lombok annotation, it will enhance java byte code within > compile > step. > We can use @Getter @Setter @Log @RequiredArgsConstructor to > define > our > model simplify. > See more detail from https://projectlombok.org < > https://projectlombok.org/ > > > any thought? > > > > > > > > > -- > Best Regards, > Yang. > >
