On Wednesday, April 2, 2025 11:44:52 AM Central European Summer Time Nicola Scendoni wrote: > On 2025/03/28 15:45:04 Oliver Lietz wrote: > > Hi Oliver,
Hi Nicola, > > > Currently, sling-commons-crypto contains both interfaces and > > > implementations. I would like to contribute to the > > > sling-auth-oauth-client > > > bundle, which depends on sling-commons-crypto, but I prefer to avoid > > > including its implementation in our product. Ideally, > > > sling-auth-oauth-client would depend on a separate SPI package, which > > > would > > > require splitting sling-commons-crypto into an API (SPI) and an > > > implementation bundle. Would you agree with this approach? > > > > What are you trying to achieve? Or what are you trying to prevent? > > The bundle is quite lightweight and all the dependencies of the included > > implementations are optional. > > Starting from the work done in sling-auth-oauth-client I'm trying to > implement an OpenID Connect Authentication Handler. My plan is to use a > different crypto provider and implement the interfaces exposed by > sling-commons-crypto. Having the interfaces and implementation in the same > package force me to include sling-commons-crypto bundle in our product > ending up with 2 crypto implementations. That shouldn't be a problem. You also have for example multiple implementations of Authentication (!), Scripting and Oak in your product. And customers can deploy additional implementations anyway for good reasons. I really see no benefit in splitting up Commons Crypto into multiple modules unless there is a second open source implementation which could be used instead of Jasypt. Sling and OSGi in general lack resources and splitting up would cause unnecessary overhead/work we could spend on other topics. I'm clearly against splitting up Commons Crypto. Regards, O. > Regards > > Nicola
