Hello, Let me add also add a couple of points: 1. It's true that is just a compile dependency but when you decide to use lombok, you also decide that everyone else who deals with your code will have to use lombok. Lombok is special in that it is a build-time dependency and your IDE needs plugins to figure out what is going on. So this is a big drawback in my opinion. 2. Going back from Lombok to without Lombok, in big projects is not easy. Delombok is not an answer, because it's not reliable. 3. We are using the javadoc on getter and setter for generating documentation, with Lombok we need to find a different way and since the code is generated I don't think it would be easy. 4. Debugging Lombok is a pain.
and I could go ahead. Il giorno dom 19 nov 2023 alle ore 14:12 Claus Ibsen <claus.ib...@gmail.com> ha scritto: > Hi > > No lombok is not allowed - we have as minimal dependency as possible. > > > > On Sun, Nov 19, 2023 at 2:06 PM Steve973 <steve...@gmail.com> wrote: > > > Hello. I completely understand the perspective of limiting the addition > of > > libraries for various reasons, and especially when the library is > included > > in the distribution. I know that I have asked about Lombok before, but > it > > is great for eliminating a lot of boilerplate code, especially when a > class > > cannot be created as a Java 17 record. Also, Lombok is a compile-only > > dependency that uses annotation processing to generate the aforementioned > > boilerplate. The license also seems compatible. Is this something that > > can be used in the coding of a component? If not, could somebody please > > explain the problem with it? > > > > Thanks, > > Steve > > > > > -- > Claus Ibsen > ----------------- > @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
