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 <claus.ib...@gmail.com> 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 <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 >
