我是Agorava的技术主管，这是一个帮助消费社交网络数据的框架。
今天，Agorava以CDI为基础，以简化其在Java EE堆栈中的使用，但我们希望为Dagger提供一个实现更轻松的Android解决方案。
我的问题是：我们可以在CDI和Dagger实现之间共享通用的JSR 330兼容代码吗？换句话说，Dagger是否可以在带有JSR 330注释的jar中编译代码，并在Dagger特定的Jar（包含@Provides，@Modules和其他Dagger特定项目中扩展或使用此代码的源代码）？
如果答案是否，是否有任何问题用Dagger编译器编译我的常见JSR 330 jar并在我的CDI实现中使用它？更确切地说，@Inject，限定符和其他JSR 330细节仍将在运行时可用，带有这些注释代码的类是否仍然不受Dagger编译器的影响？最后是否有一种关于Dagger生成的代码（类名，注释）的跟踪器，以允许CDI检测它并忽略它？
答案 0 :(得分：5)
您可以在Dagger和任何其他JSR-330实现之间共享客户端代码，只要您的代码不实现与Dagger不兼容的行为即可。例如，Dagger 1.0不支持方法注入。 Dagger 2.0使用组件接口而不是注入器，因此您的代码不必关心它。
@Inject和其他JSR-330 API元素仍会在运行时出现。 Dagger在运行时不访问它们，在编译时创建生成的代码以在运行时解释这些注释。但是这些类仍然是适用于任何JSR-330应用程序的有效JSR-330注入类。
可能有问题的是，Dagger将生成这些额外的类，您必须对jar进行后处理，或者重新配置构建系统以便去除生成的代码，并将它们移动到补充jar。但这是一个构建系统配置问题，只要生成的代码在运行时在dagger-using应用程序中可用，匕首就不可知了。
一个构建时选项是使用-proc：none运行编译器，而使用-proc：only运行第二个配置，并将后者的输出传递到另一个输出文件夹，并将其向上运行。这可以通过maven-compiler-plugin的不同执行来在maven中完成。
Dagger生成的类应该都有@Generated（即将推出），但也都来自dagger.internal.ModuleAdapter，dagger.internal.Binding或dagger.internal.StaticInjection。这些子类都可以通过非匕首框架安全地忽略。事实上，他们可以得到保护。