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 <steve...@gmail.com> 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 <steve...@gmail.com> 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 <https://projectlombok.org/features/GetterSetter> 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 <anco...@gmail.com> >> 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 <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 >>> >> >>> > >>> >>
