Closed purejava closed 3 years ago
Code that integrates a third party tool by implementing one specific interface of this lib should go into a separate library. I think this offers the best modularity for plugins. As a proof of concept the user can add the jar manually to Cryptomator. Later we can think about some UI to load jars from some Maven Repo at runtime automatically.
So for this example, I would suggest you create a new lib e.g. with Maven coordinates org.purejava:keepassxc-cryptomator
. (Or keepass-cryptomator
if the API works for all keepass flavours.)
A lib for accessing KeePassXC is already ready to be included. This is specific for KeePassXC and not generic for the keepass family, but not specific for Cryptomator also.
So the way is to create another lib org.purejava:keepassxc-cryptomator
? I thought the integrations-... are the way to add new backends? How could this new lib be integrated? Which interfaces of Cryptomator should it access?
Sorry, I am confused now.
Imagine 20 different implementations for various password managers, all residing in the same integrations-crossplatform
jar. This would foil all the modularity again. The idea behind facilitating the service loader api is to allow a variety of jars simply be added to the installation without hard-wiring anything other than integrations-api
.
Ok, now I got you. Thanks for your quick replies.
secret-service and kdewallet are linux backends and therefore reside in integrations-linux.
The same for Windows Data Protection and macOS Keychain, they live in -win and -mac.
One advantage of that separation is that packaging of installers and the Appimage can consider platform specific backends and exclude them from non-relevant platforms.
I‘d like to implement access to KeePassXC into Cryptomator, which is available cross-platform.
Do I just add it to one of the existing integrations?
I suspect, that you would prefer something like integrations-crossplatform.