我是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 检测并忽略它？
您可以在 Dagger 和任何其他 JSR-330 实现之间共享客户端代码，只要您的代码不实现与 Dagger 不兼容的行为。例如，Dagger 1.0 不支持方法注入。Dagger 2.0 使用组件接口而不是注入器，因此您的代码不必关心这一点。
@Inject 和其他 JSR-330 API 元素仍将出现在运行时。Dagger 不会在运行时访问它们，而是在编译时创建生成的代码以在运行时解释这些注释。但是对于任何 JSR-330 应用程序，这些类仍然是有效的符合 JSR-330 的可注入类。
可能有问题的是 Dagger 会生成这些额外的类，您必须对 jar 进行后处理，或者重新配置构建系统以剥离生成的代码，并将它们移动到补充 jar。但这是一个构建系统配置问题，dagger 与它无关，只要生成的代码在运行时在使用 dagger 的应用程序中可供它使用。
一个构建时选项是使用 -proc:none 运行编译器，并在第二个配置中使用 -proc:only 运行编译器，并将后者的输出通过管道传输到另一个输出文件夹，然后将其打包。这可以在 maven 中通过对 maven-compiler-plugin 进行不同的执行来完成。
Dagger 生成的类都应该有 @Generated（即将推出），但也都来自 dagger.internal.ModuleAdapter、dagger.internal.Binding 或 dagger.internal.StaticInjection。这些子类都可以被非 Dagger 框架安全地忽略。事实上，他们可以被保护起来。