Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign up宿主和插件对基础库依赖的疑惑 #429
宿主和插件对基础库依赖的疑惑 #429
Comments
|
Shadow设计时考虑的场景主要是宿主和插件的版本是多对多关系的。所以插件compileOnly依赖宿主中的实现，可能会因为实现有变化而不能兼容旧版本。因此”问题一“的这种场景，我们是需要宿主和插件约定一个不变的接口，放到白名单里，来实现插件复用宿主能力的。可以参考：https://github.com/Tencent/Shadow/tree/master/projects/sample/source/sample-host-lib/src/main/java/com/tencent/shadow/sample/host/lib VerifyError一般是因为传递依赖的一些类型由于多个ClassLoader的关系出现了不匹配的情况。所以我们在”多对多“版本场景下，不应该在白名单里声明任何有实现的类型，只声明一些空实现的接口才安全。 你的”问题二“和”问题一“是一样的。可能你需要再回顾一下ClassLoader的知识了。你的目的没问题，插件完全独立运行的构建中，可以将本来依赖宿主实现的接口在本地也打包一个实现即可。 以上谈到的东西其实跟Shadow都没有关系，都是Java的ClassLoader基本的东西。 |
|
感谢！ |
|
是对的。 如果还是遇到困难，最好就是通过PR向Shadow的sample 补充你需要的场景。遇到解决不了的问题，方便交流，也方便合作解决。 |
问题一：
我们有一些基础功能的封装，在宿主和插件都用到了，宿主工程肯定用的implementation依赖，请问插件是通过 compileOnly，然后配置白名单还是通过来implementation的依赖呢，有什么建议。我理解的是implementation依赖会导致插件包体积变大，使用 compileOnly更好一些，但是经常出现如下错误。
java.lang.VerifyError: Verifier rejected class
问题二：
application的classload和插件application的classload不是一个，如果插件和宿主同时依赖了一个单例，由于classload的不同造成
单例创建了两个，如果插件通过白名单依赖，此时单例是一个，但是该单例的classload是宿主的，在该单例中遇到CLass.forName无法创建插件的类，虽然通过指定使用插件的classload可以解决，但是不知道还有其他什么潜在问题吗
现在想法是插件宿主尽可能独立，少使用白名单，尽可能保持插件的完全独立运行，忽略插件的大小这样对吗
想问作者对插件和宿主依赖同一个库有什么建议吗， 谢谢