1. 一个项目内，不想代码重复的时候，靠 import 复用 2. 多个项目间，不想代码重复的时候，只能靠 Jar 包了，另外也可以保护 Jar 包中的代码，不被别人随意修改。 Spring Boot 在打包部署的时候打包成 jar 和 war 有什么不同? - 皮蛋 XXXXL 的回答 - 知乎 https://www.zhihu.com/question/283746123/answer/2046064283 ## 为啥这个项目只有src/test/resources/logback.xml下面有 logback 的配置，main下面没有？  明白了，这是一个被其他项目引用的 jar 包。这种情况下，只在 `src/test/resources` 下有 `logback.xml` 是很常见且合理的做法。让我解释一下原因： 1. 测试独立性： - `src/test/resources` 下的 `logback.xml` 只用于这个 jar 包自身的单元测试和集成测试。 - 这确保了在运行测试时可以有特定的日志配置，而不会影响到使用这个 jar 包的其他项目。 2. 避免配置冲突： - 如果在 `src/main/resources` 中也包含 `logback.xml`，它会被打包到最终的 jar 中。 - 这可能会导致使用这个 jar 包的项目在类路径上有多个 `logback.xml`，造成配置冲突。 3. 灵活性： - 不在主资源中包含日志配置，允许使用这个 jar 包的项目自由配置自己的日志策略，而不被这个库的配置所限制或影响。 4. 关注点分离： - 作为一个库或组件，它应该专注于提供功能，而将日志配置的决定权留给使用它的应用程序。 5. 测试专用配置： - 测试时可能需要更详细的日志输出，`src/test/resources` 下的配置允许在不影响实际使用时进行更详细的日志记录。 6. 最小依赖原则： - 不包含主日志配置有助于减少这个 jar 包对特定日志实现的依赖，使其更加通用。 建议： - 确保这个 jar 包中的代码使用 SLF4J 或其他日志门面接口进行日志记录，而不是直接依赖于特定的日志实现。 - 在这个 jar 包的文档中，清楚地说明它使用的日志框架和任何相关的配置建议，以便使用者正确配置日志。 - 如果这个 jar 包需要在某些情况下输出特定的日志信息，考虑提供编程方式的日志配置选项，而不是依赖于配置文件。 总的来说，这种设置是很好的实践，它保持了库的灵活性和可用性，同时仍然为其自身的测试提供了必要的日志配置。 ## 构建一个 JAR 包时，需要注意以下几个关键方面 1. 依赖管理： - 使用依赖管理工具（如Maven或Gradle）来管理外部库依赖。 - 仔细考虑哪些依赖应该被标记为 "provided" 或 "compile"，避免不必要的传递依赖。 - 使用依赖范围（scope）来区分编译时、运行时和测试时依赖。 2. 版本控制： - 为JAR包使用语义化版本号（Semantic Versioning）。 - 在 `pom.xml` 或 `build.gradle` 中明确指定版本号。 3. 打包配置： - 确保 `logback.xml`0 文件包含正确的信息（如版本、构建日期等）。 - 如果JAR是可执行的，指定正确的 Main-Class。 - 考虑是否需要打包源代码（source JAR）和JavaDoc。 4. 资源文件： - 确保必要的配置文件、属性文件等被正确包含在JAR中。 - 避免包含敏感信息或环境特定的配置。 5. 测试： - 包含单元测试和集成测试，确保在不同环境下JAR包可以正常工作。 - 考虑使用测试覆盖率工具来评估测试的完整性。 6. 文档： - 生成和包含JavaDoc。 - 提供清晰的README文件，说明JAR包的用途、如何使用、配置选项等。 7. 许可证： - 清楚地指明JAR包的许可证信息。 - 确保遵守所有使用的第三方库的许可条款。 8. 兼容性： - 明确支持的Java版本范围。 - 考虑向后兼容性，避免不必要的破坏性变更。 9. 安全性： - 避免在JAR中包含敏感信息或硬编码的凭证。 - 考虑使用安全扫描工具检查潜在的漏洞。 10. 日志处理： - 使用日志门面（如SLF4J）而不是具体实现，增加灵活性。 - 不要在JAR中包含具体的日志配置文件。 11. 模块化： - 如果针对Java 9+，考虑是否需要使用Java模块系统（JPMS）。