Lombok have advantages and disadvantages both.
With bringing reducing of annoying boilerplate it brings its "magic" of
underlying code generation which could be understood only by having some
level of practice using Lobmok. For example, deserialization troubles
when a constructor have more than one parameter with the same type (it
needs to be annotated with @Creator or @ConstructorProperties). I guess,
the maintainers of Camel don't want to be involved into such issues.
On 11/3/21 00:35, Steve973 wrote:
You see no advantage in getting boilerplate code for free, and keeping your
beans, etc, free from accessors/mutators, no arg constructors, all arg
constructors, getting a builder for free, and lots of other stuff? I can
see avoiding it in a project for particular reasons, but most of the
"favorite" frameworks reduce a lot of boilerplate code, and Camel is
included in that. I'm not arguing, but I really am curious why you see no
advantage. That is, of course, if it's appropriate to have this
conversation here, on this list.
On Tue, Nov 2, 2021 at 5:31 PM Andrea Cosentino <[email protected]> wrote:
There is no problem with license. Personally i never find any advantage in
using Lombok.
Il mar 2 nov 2021, 21:23 Steve973 <[email protected]> ha scritto:
Hello. I normally use lombok to take care of boiler plate code in
projects
that I work on. I have noticed that lombok is not used in the camel code
base. Is there something about it (licensing or something else) that
makes
it unsuitable for camel? I am working on something in camel-core, and it
would be great to be able to use it to keep things cleaner. But I would
think that if it was acceptable in an apache project, people would
already
be using it. Does anyone have the details on this?
Thanks,
Steve
