Support java 8

[SettingDust]

IDK if it is in your scope. But I open this for anyone need this. I've created a fork for this. Will you guys accept a PR for that?

[acrusage-iaik]

Hello,

IDK if it is in your scope.

There is currently no roadmap for more features

But I open this for anyone need this. I've created a fork for this. Will you guys accept a PR for that?

Yes, a PR would be reviewed and merged if it is acceptable

[SettingDust]

It's replaced Napier with kotlin logging that is supporting java 8. Will it be acceptable?

[JesusMcCloud]

Hi! we do appreciate the effort getting all the info needed up-front!

Hopefully, I can return the favour with actually providing all that info here:
If you split the project up into two variants (one for java8 with Kotlin logging and one for java17+ with napier) with proper publishing and document everything accordingly, it is perfectly fine. We can't really do without Napier, since we use it everywhere internally (specifically in projects depending on JsonPath4K).

In the end, I imagine two artifacts being published: jsonpath4k (as it is now) and jsonpath4k-jdk8 using kotlin-logging instead of Napier, targeting Java 8. I would forego adding a common module that both depend on (since we're only talking logging here).

Instead I imagine two modules with source sets that share one directory:

     JsonPath4K                    JsonPath4K-jdk8   
          │                               │          
          │                               │          
          ▼                               ▼          

commonMain Source Set           commonMain Source Set
                  │                             │    
                  │                             │    
                  │            ┌──────────┬─────┘    
       ┌──────────┴──┐         │          │          
       │             │         │          │          
       │             │         │          │          
       │             │         │          │          
       │         ┌───▼─────────▼───┐      │          
       │         │                 │      │          
 ┌─────▼─┐       │  Shared Logic   │   ┌──▼────┐     
 │Napier │       │                 │   │koltin │     
 │Logging│       │Logging-Interface│   │logging│     
 └───────┘       │                 │   └───────┘     
                 └─────────────────┘                 

The middle box is the directory shared by both module's source sets. it should contain some interface for logging. The left and right directories implement it using napier and kotlin-logging, respectively. The main difference to the status quo is not using a single Napier-object in the shared sources, but some variable that is initialised based in the logging-framework-specific sources.

D'accord?

[JesusMcCloud]

just in case: you can add sourceDirs to any source set like so: https://github.com/a-sit-plus/android-attestation/blob/main/android-attestation/build.gradle.kts#L30

[SettingDust]

Instead I imagine two modules with source sets that share one directory

You mean the both loggers should be 2 modules?

[JesusMcCloud]

This is what I had in mind.

Note: this is a very rough sketch, probably breaking publishing and dokka. The lateinit hack with the duplicated JsonPath class is also nasty, but it should be straight-forward to get the general idea I'm trying to convey. Feel free to take it as a basis for your efforts but be sure that publishing and dokka works when you're done (publishAllPublicationsToLocalRepository is your friend).

In the end, everything but the call to the actual logging framework should be in ${project.rootDir}/src/commonMain/, including the grammar files. you'll also want to externalise common build setup stuff to buildScr or something similar to avoid duplication to keep everything maintainable (a custom gradled plugin is overkill, if you ask me). Also: I don't think and XCFramework makes sense for the jdk8 module.

Feel free to go down a different route, but I had bad experiences in the past with the kotlin gradle plugin for KMP projects doing custom variant stuff. As long as the end result does not needlessly duplicate stuff and remains maintainable, knock yourself out in whichever way you see fit!

Happy hacking!

[JesusMcCloud]

Addendum: if you do get the MR-Jar-Plugin to work flawlessly within a kotlin mutliplatform project, that would be really awesome, because then no fiddling whatsoever would be needed and we'd have a single module with a single output catering to jdk8 and jdk17+. It's just that I did not get it to work and the resulting jars were always broken. The Kotlinlang Slack is probably the place to go for help!

[mervyn-mccreight]

How about naming it differently, since the only real difference is the used logging library. To me it sounds like supporting jdk8 is just a "side-effect" of using a different logging library.

I'd imaging something like having JsonPath4k-core or something with just the logging interface - and then other modules that are providing the respective logging-library implementations for it. It'd make it independent from the logging solution and more open to anyone. If anyone is using even another logging solution they could either provide a PR for another logging-module or simply implement it theirselves in their project.

[JesusMcCloud]

I agree on a conceptual level and I do appreciate the idea. In practice though, a logging facade for plugging in logging facades is one layer of indirection too many for my taste. In addition: wiring up everything as sketched here, is closer to a chore than a real brain teaser. Than being said, it does requires at least intermediate knowledge about gradle and the KGP, including its kinks, how it likes to break the task graph and maybe even how to out-smart it in case it refuses to play along nicely.