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 <claus.ib...@gmail.com> wrote: > 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 > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
