Re: Question about Lombok use

[Steve973]

Claus (and others),

Thank you for sharing your thoughts.  I do not think any of that is harsh,
because it makes perfect logical sense, and it is what I figured.  I
thought I would ask, just in case.  I apologize if my questions were
annoying, and/or a waste of time.  Even though I asked these questions
today, I am perfectly fine with sticking with standard Java and its tools.
Thank you for your patience and good/quick responses.

On Sun, Nov 19, 2023 at 10:36 AM Claus Ibsen  wrote:

> Hi
>
> Okay it may sound harsh when I and other long term Camel core team
> members say No to X or Y.
> However its a very large code base and a project that is ongoing for
> decades, currently 16 and half years old.
> People come and go, and it's important that everything in Camel can be
> picked up and maintained - also components contributed originally be
> someone whom have left.
> For example if you leave and we have to keep maintaining the dynamic router
> component, and we have not spent hours into its code base, and then have
> trouble doing so
> because of bringing in the original author's favourite set of tools.
> And even more now with a lot of focus on CVEs are other scanner tools that
> make people nervous if they report something, and you have to constantly
> chase around and update dependencies.
>
> The code must be easier to maintain and last for decades. And this means
> its standard Java only, and minimal dependencies. And uses Maven only as a
> build system.
> And that it must work with build from Maven (frankly the maven wrapper we
> have in the source).
> The camel builds system is also doing more than just compiling. We have all
> components generate metadata that gets into a camel-catalog, and also into
> generated DSLs (endpoint and component DSLs).
> And we have a route parser library that can scan the source code and
> generate a "visual report" etc that we use for tooling
> (camel-maven-report-plugin) etc.
> All of this makes it harder to maintain if components are not uniform
> around being standard Java only.
>
> The only place we have some non Java code is in the DSLs for groovy, kotlin
> etc.
>
> And also the camel-yaml-dsl unit tests are groovy based. But that is a semi
> mistake and we eventually need to migrate that to plain Java.
> But those tests are 95% focused only on loading some YAML and parse it via
> the yaml-dsl parser, and not a ton of groovy code.
>
> On the other side its is 100% okay to contribute examples that used Kotlin,
> Lombok and have them on your own code repositories,
> but also contribute some of these to Apache Camel in our example repos.
> However the vast majority of those examples should be maintains Java and
> easy to maintain as well.
> But we are fine with having a set of examples that uses what I mentioned
> before.
>
> And as a component developer you will find out - okay I need to add many
> unit tests to cover all its features and help ensure higher QE and ... yes
> that means something you
> need to write more unit tests code in standard Java with JUnit. And yes we
> use docker test containers for integration tests, and there is the
> "camel-test-infra" that can make this easier.
>
>
>
>
> On Sun, Nov 19, 2023 at 2:12 PM Claus Ibsen  wrote:
>
> > Hi
> >
> > No lombok is not allowed - we have as minimal dependency as possible.
> >
> >
> >
> > On Sun, Nov 19, 2023 at 2:06 PM Steve973  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
> >
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Question about Lombok use

[Grzegorz Grzybek]

Big -1 for Lombok from me.

I fully agree with Andrea and Claus about this. Especially #4 - debugging
problems.

Saving few lines in Java code which would take you a minute to write,
comparing to seconds of lombok annotation is nothing comparing to
maintenance pain over years. Been there, done that.

Java's verbosity is its big (huge) advantage. After writing and reading
Java code for over 20 years now, I can firmly say - 90% of my professional
career is reading code, 5% is writing and 5% is for meetings.

I know there are handy Lombok annotations and when company policy allows
it, use it (let your entire team use it). But for libraries/frameworks like
Camel there's not advantage at all.

kind regards
Grzegorz Grzybek

niedz., 19 lis 2023 o 16:36 Claus Ibsen  napisał(a):

> Hi
>
> Okay it may sound harsh when I and other long term Camel core team
> members say No to X or Y.
> However its a very large code base and a project that is ongoing for
> decades, currently 16 and half years old.
> People come and go, and it's important that everything in Camel can be
> picked up and maintained - also components contributed originally be
> someone whom have left.
> For example if you leave and we have to keep maintaining the dynamic router
> component, and we have not spent hours into its code base, and then have
> trouble doing so
> because of bringing in the original author's favourite set of tools.
> And even more now with a lot of focus on CVEs are other scanner tools that
> make people nervous if they report something, and you have to constantly
> chase around and update dependencies.
>
> The code must be easier to maintain and last for decades. And this means
> its standard Java only, and minimal dependencies. And uses Maven only as a
> build system.
> And that it must work with build from Maven (frankly the maven wrapper we
> have in the source).
> The camel builds system is also doing more than just compiling. We have all
> components generate metadata that gets into a camel-catalog, and also into
> generated DSLs (endpoint and component DSLs).
> And we have a route parser library that can scan the source code and
> generate a "visual report" etc that we use for tooling
> (camel-maven-report-plugin) etc.
> All of this makes it harder to maintain if components are not uniform
> around being standard Java only.
>
> The only place we have some non Java code is in the DSLs for groovy, kotlin
> etc.
>
> And also the camel-yaml-dsl unit tests are groovy based. But that is a semi
> mistake and we eventually need to migrate that to plain Java.
> But those tests are 95% focused only on loading some YAML and parse it via
> the yaml-dsl parser, and not a ton of groovy code.
>
> On the other side its is 100% okay to contribute examples that used Kotlin,
> Lombok and have them on your own code repositories,
> but also contribute some of these to Apache Camel in our example repos.
> However the vast majority of those examples should be maintains Java and
> easy to maintain as well.
> But we are fine with having a set of examples that uses what I mentioned
> before.
>
> And as a component developer you will find out - okay I need to add many
> unit tests to cover all its features and help ensure higher QE and ... yes
> that means something you
> need to write more unit tests code in standard Java with JUnit. And yes we
> use docker test containers for integration tests, and there is the
> "camel-test-infra" that can make this easier.
>
>
>
>
> On Sun, Nov 19, 2023 at 2:12 PM Claus Ibsen  wrote:
>
> > Hi
> >
> > No lombok is not allowed - we have as minimal dependency as possible.
> >
> >
> >
> > On Sun, Nov 19, 2023 at 2:06 PM Steve973  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
> >
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Question about Lombok use

[Claus Ibsen]

Hi

Okay it may sound harsh when I and other long term Camel core team
members say No to X or Y.
However its a very large code base and a project that is ongoing for
decades, currently 16 and half years old.
People come and go, and it's important that everything in Camel can be
picked up and maintained - also components contributed originally be
someone whom have left.
For example if you leave and we have to keep maintaining the dynamic router
component, and we have not spent hours into its code base, and then have
trouble doing so
because of bringing in the original author's favourite set of tools.
And even more now with a lot of focus on CVEs are other scanner tools that
make people nervous if they report something, and you have to constantly
chase around and update dependencies.

The code must be easier to maintain and last for decades. And this means
its standard Java only, and minimal dependencies. And uses Maven only as a
build system.
And that it must work with build from Maven (frankly the maven wrapper we
have in the source).
The camel builds system is also doing more than just compiling. We have all
components generate metadata that gets into a camel-catalog, and also into
generated DSLs (endpoint and component DSLs).
And we have a route parser library that can scan the source code and
generate a "visual report" etc that we use for tooling
(camel-maven-report-plugin) etc.
All of this makes it harder to maintain if components are not uniform
around being standard Java only.

The only place we have some non Java code is in the DSLs for groovy, kotlin
etc.

And also the camel-yaml-dsl unit tests are groovy based. But that is a semi
mistake and we eventually need to migrate that to plain Java.
But those tests are 95% focused only on loading some YAML and parse it via
the yaml-dsl parser, and not a ton of groovy code.

On the other side its is 100% okay to contribute examples that used Kotlin,
Lombok and have them on your own code repositories,
but also contribute some of these to Apache Camel in our example repos.
However the vast majority of those examples should be maintains Java and
easy to maintain as well.
But we are fine with having a set of examples that uses what I mentioned
before.

And as a component developer you will find out - okay I need to add many
unit tests to cover all its features and help ensure higher QE and ... yes
that means something you
need to write more unit tests code in standard Java with JUnit. And yes we
use docker test containers for integration tests, and there is the
"camel-test-infra" that can make this easier.




On Sun, Nov 19, 2023 at 2:12 PM Claus Ibsen  wrote:

> Hi
>
> No lombok is not allowed - we have as minimal dependency as possible.
>
>
>
> On Sun, Nov 19, 2023 at 2:06 PM Steve973  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
>


-- 
Claus Ibsen
-
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Question about Lombok use

[Steve973]

If the component codebase is java-only, is it permissible to use test
frameworks that use other JVM languages?  I am talking about things like
Spock or Kotest.

On Sun, Nov 19, 2023 at 9:21 AM Steve973  wrote:

> Oh, regarding my other question, which might have gotten lost among the
> bigger discussion about Lombok: is the camel component codebase java-only,
> or is Kotlin also ok?
>
> On Sun, Nov 19, 2023 at 9:20 AM Steve973  wrote:
>
>> Thanks, Andra, for the informative reply.  I understand and appreciate
>> your assessment, and it seems like the correct decision for Apache
>> Camel, given your reasoning.  That clears a lot of things up for me.  My
>> questions are only out of curiosity, so I hope this discussion is
>> reasonable and welcome for you and Claus.  Making the decision for everyone
>> else -- a considerably large community -- is, perhaps, my favorite point on
>> your list.  I had not considered that, but that's huge!  It is also good to
>> know that delombok might not be reliable, since I have not used it before.
>> I will keep that in mind in the future.  I am going to experiment with
>> that, so that I might know what to expect.
>>
>> For only the sake of this discussion (and not in the hope that the use of
>> lombok might be reconsidered), I would like to offer a couple of points for
>> lombok use *outside of Camel and its related repositories*:
>> 1. Since version 1.12, javadoc is handled quite well, and you can see
>> more here  at the end
>> of the "overview" section (at the top).
>> 2. For me, it is not a matter of laziness; as you said, most of the
>> boilerplate is easily generated by IDEs.  To me, it is a matter of "
>> *boilerplate noise"*.  When I look at source code, and when most of the
>> code that is on my screen is only the business logic, then that makes for a
>> nicely decluttered view.  As a workaround, we could utilize things like
>> editor folding regions for getter/setter methods.  Another workaround, for
>> builders, is to use an IDE plugin to generate them.
>>
>> Thanks again!  I always enjoy the discussion.
>>
>> On Sun, Nov 19, 2023 at 8:51 AM Andrea Cosentino 
>> wrote:
>>
>>> Last but not least, there are no clear, IMO, advantages is using it,
>>> despite the fact you'll see less boilerplate code. This laziness is
>>> something I don't understand. IDEs will generate setters/getters for you
>>> just with a shortcut on classes with thousands of fields.
>>>
>>> Il giorno dom 19 nov 2023 alle ore 14:47 Andrea Cosentino <
>>> anco...@gmail.com>
>>> ha scritto:
>>>
>>> > 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  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
>>> >>
>>> >
>>>
>>

Re: Question about Lombok use

[Steve973]

Oh, regarding my other question, which might have gotten lost among the
bigger discussion about Lombok: is the camel component codebase java-only,
or is Kotlin also ok?

On Sun, Nov 19, 2023 at 9:20 AM Steve973  wrote:

> Thanks, Andra, for the informative reply.  I understand and appreciate
> your assessment, and it seems like the correct decision for Apache
> Camel, given your reasoning.  That clears a lot of things up for me.  My
> questions are only out of curiosity, so I hope this discussion is
> reasonable and welcome for you and Claus.  Making the decision for everyone
> else -- a considerably large community -- is, perhaps, my favorite point on
> your list.  I had not considered that, but that's huge!  It is also good to
> know that delombok might not be reliable, since I have not used it before.
> I will keep that in mind in the future.  I am going to experiment with
> that, so that I might know what to expect.
>
> For only the sake of this discussion (and not in the hope that the use of
> lombok might be reconsidered), I would like to offer a couple of points for
> lombok use *outside of Camel and its related repositories*:
> 1. Since version 1.12, javadoc is handled quite well, and you can see more
> here  at the end of the
> "overview" section (at the top).
> 2. For me, it is not a matter of laziness; as you said, most of the
> boilerplate is easily generated by IDEs.  To me, it is a matter of "
> *boilerplate noise"*.  When I look at source code, and when most of the
> code that is on my screen is only the business logic, then that makes for a
> nicely decluttered view.  As a workaround, we could utilize things like
> editor folding regions for getter/setter methods.  Another workaround, for
> builders, is to use an IDE plugin to generate them.
>
> Thanks again!  I always enjoy the discussion.
>
> On Sun, Nov 19, 2023 at 8:51 AM Andrea Cosentino 
> wrote:
>
>> Last but not least, there are no clear, IMO, advantages is using it,
>> despite the fact you'll see less boilerplate code. This laziness is
>> something I don't understand. IDEs will generate setters/getters for you
>> just with a shortcut on classes with thousands of fields.
>>
>> Il giorno dom 19 nov 2023 alle ore 14:47 Andrea Cosentino <
>> anco...@gmail.com>
>> ha scritto:
>>
>> > 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  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
>> >>
>> >
>>
>

Re: Question about Lombok use

[Steve973]

Thanks, Andra, for the informative reply.  I understand and appreciate your
assessment, and it seems like the correct decision for Apache Camel, given
your reasoning.  That clears a lot of things up for me.  My questions are
only out of curiosity, so I hope this discussion is reasonable and welcome
for you and Claus.  Making the decision for everyone else -- a considerably
large community -- is, perhaps, my favorite point on your list.  I had not
considered that, but that's huge!  It is also good to know that delombok
might not be reliable, since I have not used it before.  I will keep that
in mind in the future.  I am going to experiment with that, so that I might
know what to expect.

For only the sake of this discussion (and not in the hope that the use of
lombok might be reconsidered), I would like to offer a couple of points for
lombok use *outside of Camel and its related repositories*:
1. Since version 1.12, javadoc is handled quite well, and you can see more
here  at the end of the
"overview" section (at the top).
2. For me, it is not a matter of laziness; as you said, most of the
boilerplate is easily generated by IDEs.  To me, it is a matter of "
*boilerplate noise"*.  When I look at source code, and when most of the
code that is on my screen is only the business logic, then that makes for a
nicely decluttered view.  As a workaround, we could utilize things like
editor folding regions for getter/setter methods.  Another workaround, for
builders, is to use an IDE plugin to generate them.

Thanks again!  I always enjoy the discussion.

On Sun, Nov 19, 2023 at 8:51 AM Andrea Cosentino  wrote:

> Last but not least, there are no clear, IMO, advantages is using it,
> despite the fact you'll see less boilerplate code. This laziness is
> something I don't understand. IDEs will generate setters/getters for you
> just with a shortcut on classes with thousands of fields.
>
> Il giorno dom 19 nov 2023 alle ore 14:47 Andrea Cosentino <
> anco...@gmail.com>
> ha scritto:
>
> > 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  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
> >>
> >
>

Re: Question about Lombok use

[Andrea Cosentino]

Last but not least, there are no clear, IMO, advantages is using it,
despite the fact you'll see less boilerplate code. This laziness is
something I don't understand. IDEs will generate setters/getters for you
just with a shortcut on classes with thousands of fields.

Il giorno dom 19 nov 2023 alle ore 14:47 Andrea Cosentino 
ha scritto:

> 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  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
>>
>

Re: Question about Lombok use

[Andrea Cosentino]

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 
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  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
>

Re: Question about Lombok use

[Steve973]

Does that preference extend to compile-time only, as well?  The scope of
lombok is always set to "provided", so it is never included at runtime.  I
am also curious if any components can be written in other JVM languages,
such as Kotlin (since camel includes the Kotlin DSL), or if it's java-only.

On Sun, Nov 19, 2023 at 8:12 AM Claus Ibsen  wrote:

> Hi
>
> No lombok is not allowed - we have as minimal dependency as possible.
>
>
>
> On Sun, Nov 19, 2023 at 2:06 PM Steve973  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
>

Re: Question about Lombok use

[Claus Ibsen]

Hi

No lombok is not allowed - we have as minimal dependency as possible.



On Sun, Nov 19, 2023 at 2:06 PM Steve973  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

Question about Lombok use

[Steve973]

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