Added kotlin-logging and tinylog

[altro3]

No description provided.

[altro3]

@graemerocher look to this, pls

[sdelamo]

are we using tinylog or kotlin-logging anywhere in the framework?

My opinion is that we should not add versions in Micronaut BOMs for dependencies we don't use. We could offer these features in starter.

[altro3]

@sdelamo About kotlin-logging: if we are using slf4j in kotlin modules - it's better to use kotlin-logging as an add-on for slf4j - better integration with Kotlin capabilities.

I'm sure this should be in the versions directory and bom file, because... this solution is really convenient and popular for Kotlin.

About tinylog:

Hmm.. this project describes all the most popular loggers in the world for java. The only thing missing is tinylog for full support. But this is not mandatory, rather as a suggestion.

In general, I am in favor of being able to use only the Micronaut platform to control 99% of library versions, i.e. so that there are fewer problems with versioning libraries at the project level. I'm not saying that you need to add all known libraries, but you should definitely add popular solutions

[sdelamo]

@sdelamo About kotlin-logging: if we are using slf4j in kotlin modules - it's better to use kotlin-logging as an add-on for slf4j - better integration with Kotlin capabilities.

I'm sure this should be in the versions directory and bom file, because... this solution is really convenient and popular for Kotlin.

About tinylog:

Hmm.. this project describes all the most popular loggers in the world for java. The only thing missing is tinylog for full support. But this is not mandatory, rather as a suggestion.

In general, I am in favor of being able to use only the Micronaut platform to control 99% of library versions, i.e. so that there are fewer problems with versioning libraries at the project level. I'm not saying that you need to add all known libraries, but you should definitely add popular solutions

why don't add them as starter features? If we don't use them, I don't see any point on having them in the BOM. Lets the user control the version number of those dependencies.

[altro3]

I still can't understand your logic. More precisely, I understand the logic, but I don’t understand why you always think only about the framework, and not about the final products and users of the framework.

Obviously, it is not necessary to add popular solutions to the final bom file. BUT! When there are versions of almost all the tools that you need inside the platform that Micronaut provides, there is much more programming.

So then it’s worth answering the question - what goals does the micronaut pursue? Creating just another framework with its pros and cons, or is it an attempt to create a framework that will be not only the fastest, but also the most convenient in every sense.

By the way, the same applies to testContainers - it is used for testing some modules, but, again, it is not in the final bom file and end users are forced to write a version of testcontainers in each of their projects.

As a result, adding a library to the final directory and bom file does not affect performance in any way and does not complicate the code, but you choose some strange style - we do it well, but we will not do some things that would make your life easier on purpose. Yes, we know that this will help many and will not complicate our project, but we will not do this because of some internal illogical principles.

[sdelamo]

I have created features in starter:

• Create a feature for kotlin-logging micronaut-starter#2154
• Create a feature for tinylog micronaut-starter#2153

[sdelamo]

I still can't understand your logic. More precisely, I understand the logic, but I don’t understand why you always think only about the framework, and not about the final products and users of the framework.

Obviously, it is not necessary to add popular solutions to the final bom file. BUT! When there are versions of almost all the tools that you need inside the platform that Micronaut provides, there is much more programming.

So then it’s worth answering the question - what goals does the micronaut pursue? Creating just another framework with its pros and cons, or is it an attempt to create a framework that will be not only the fastest, but also the most convenient in every sense.

By the way, the same applies to testContainers - it is used for testing some modules, but, again, it is not in the final bom file and end users are forced to write a version of testcontainers in each of their projects.

As a result, adding a library to the final directory and bom file does not affect performance in any way and does not complicate the code, but you choose some strange style - we do it well, but we will not do some things that would make your life easier on purpose. Yes, we know that this will help many and will not complicate our project, but we will not do this because of some internal illogical principles.

I do many things wrong, but I never thought someone would tell me that I don't think about the final product or the users of Micronaut Framework.

For me, Micronaut framework BOMs are a contract with our users. In that contract, we tell them that the versions specified in the BOM play well with each other, and we have tested them. Thus, we say to our users that if they use these libraries with the version coming from the platform BOM, we guarantee that they work fine.

As a Micronaut user, you can use any Java library, but we only offer guarantees for what we have tested.

We don't add versions in the BOM only to avoid the user specifying a version in their build file.

Adding starter features for kotlin-logging and tinylog is a good first step to integrate those libraries into the framework.

By the way, the same applies to testContainers - it is used for testing some modules, but, again, it is not in the final bom file and end users are forced to write a version of testcontainers in each of their projects.

I think we could consider adding the testcontainers BOM version to one of the framework's BOM. It should be in test resources BOM or test BOM. We use TestContainers so much throughout the framework to test it and in Micronaut Test Resources I think it is safe to add it.

[CLAassistant]

All committers have signed the CLA.

[altro3]

Regarding Kotlin logging: I think you can say with confidence that you also support this logger. Once again: Kotlin logging is NOT a separate logger, like logback and log4j. This is just a superset of slf4j with advanced features for ease of use in Kotlin. Those. it does NOT work without slf4j.

Tinylog is the only alternative to all previous loggers today. All other loggers are not popular.

Adding to the starter will not bring the desired effect, this is 100%. the case that the starter solves and the problem that the developers face are not the same thing. I'm trying to solve the problem of registering a million versions in my projects or the need to create my own BOM file.

Starter is a project for beginners, unfortunately, it does not play a role for experienced developers and adding these features there will not help experienced developers in any way.

As I said earlier, I want to use Macronaut specifically as a platform, and not as part of the platform, and minimize problems with other libraries. I want Micronaut to give you the opportunity to focus on business logic, and not on the environment, if you know what I mean. Adding these two loggers will close the issue of choosing a logging system for a long time, until another popular logging system appears.

Regarding the guarantee of operation: judging by the number of bugs and how long they hang, the current guarantee is not much different from adding a library and if someone has problems (the probability of which is negligible in this case), then they can simply add a ticket for problems with work and he will be corrected in the same way as everyone else.

In general, I’m saying all this to mean that it’s worth reconsidering the policy regarding BOM files. This is also 100%

[graemerocher]

I don't think we should add modules to the BOMs without tests a minimum requirement to adding these modules is IMO tests that verify they work in both native and JIT

Something that is added to our BOM is an expression to our users that we have tested and know the module to work correctly.

[altro3]

@graemerocher No problem! But how do you suggest I test the work? I mean, what should the tests look like in this module? Now logback and log4j are connected, but there are no tests for them. Need some example

[sdelamo]

These are examples:
https://github.com/micronaut-projects/micronaut-crac/blob/cc5e1e962cfcaa77db71df1f1808f04e05bd0372/crac/src/test/groovy/io/micronaut/crac/HikariSpec.groovy

https://github.com/micronaut-projects/micronaut-core/tree/4.2.x/test-suite-logback-graalvm https://github.com/micronaut-projects/micronaut-core/tree/4.2.x/test-suite-logback

I'm trying to solve the problem of registering a million versions in my projects or the need to create my own BOM file.

I don't think the solution is to add the versions of the libraries you use in the framework BOMs.

Starter is a project for beginners, unfortunately, it does not play a role for experienced developers and adding these features there will not help experienced developers in any way.

I don't think experienced developers have problems understanding a version number in a maven coordinate.

[sdelamo]

Closing this for now.