常见问题
具体项目常见问题请移步对应项目文档。
谁在维护 ContiNew？
ContiNew 系列项目是独立的社区驱动项目。首个项目 ContiNew Admin 由 Charles 于 2022 年底作为个人项目创建。如今，ContiNew 由 来自全国各地的非全职成员团队 积极维护，并由 Charles 担任各项目负责人。你可以在 发展历程 中了解更多关于 ContiNew 社区的故事。
如果你或你的企业从 ContiNew 中受益，请考虑 赞助 我们，以支持 ContiNew 的发展！
ContiNew 使用什么开源协议？
| 项目 | 协议 | 是否可商用 |
|---|---|---|
| ContiNew Admin | Apache-2.0 开源许可协议 | 完全免费用于开发商业应用 |
| ContiNew Starter | LGPL-3.0 开源许可协议 | 通过 Maven/Gradle 等依赖方式完全免费用于开发商业应用 |
Starter 为什么采用 LGPL-3.0 开源协议？
有不少人争议 ContiNew Starter 为什么采用了 LGPL-3.0 开源许可协议？其实这个开源协议本身没有任何问题，出发点就是希望能够汇集更多人的智慧，使通用的东西更加通用。但总有人看惯了 Apache-2.0 和 MIT 之后，下意识就认为这不可商用，这里统一说明一下：
从 ContiNew Admin v2.1.0 版本开始，我们调整了总体设计，抽取并封装后端基础组件及各框架通用集成配置 到 ContiNew Starter 项目。Admin 项目被设计为一个解决方案框架，提供通用应用和方案，而 Starter 项目则是被设计为一个应用脚手架，且发布至了 Maven 中央仓库，这意味着你可以在任意项目中直接引入所需依赖来使用这些配置。即使你不用 Admin 项目，你依然可以直接选择这些 Starter 来让你的 Spring Boot 程序开发变得更 easy！
Starter 的优势：
- 易于迁移： 我们选择一个程序框架的原因就是希望减少重复功能开发，实际上框架带来的不仅仅是成品功能，还有成品的基础配置。你要开始一个 Spring Boot 项目开发，你不需要配置 JSON、API 接口文档、跨域、线程池等配置吗？如果这些配置代码全都在 Admin 里，没有 Starter，那你需要从 Admin 里复制很多的配置到新项目，或者说你要从程序框架中删除很多的配置代码。你能处理好，处理完整吗？你不累吗？我作为使用者之一，我感觉累。
- 易于扩展： 我们针对于 Starter 的开发目标就是通用且基础，不含业务逻辑，在设计和开发某个 starter 模块时，已尽可能开放了更多的“口子”可以进行重写或覆盖，你不妨看看代码。且未来在持续的重构中会继续优化完善，开放更多的“口子”，适配更多的可能，这恰恰需要更多人的智慧。
要改代码怎么办？
Starter 是一系列组件，如果“口子”不够大，你可以反馈一下我们一起讨论完善，发布个版本很快的。如果不满足你需求，要完全重构，这种场景你完全可以不引入某个 Starter，自己去编写一个自己内部的 Starter，亦或者关闭某个 Starter 的某些配置，改为采用自己的。（LGPL 涉及到的二次开发并不包含重写覆盖配置 @Bean、@Override，这是面向对象和 IOC 的魅力，和开源协议并不冲突，不要过于担忧协议范围）你换个参照物想一下，你把它当成 Hutool 工具库，Hutool 里有的工具方法你直接用，Hutool 里没有的你不也需要自己写或基于 Hutool 里的方法继续封装工具类吗？这难道也要担心涉及侵权吗？当然了，如果是改改包名或简单改动就发布为了另一个项目，我觉得懂点法律身怀正气的你都知道这没什么必要。
- 易于上手： 抽离了那些基础配置，Admin 就是一个纯粹的业务解决方案项目，大多数人需要的就是这么纯粹的内容。即使你是个新手，想要上手这个项目，你不需要关注那么多的其他配置了，甚至说它们对初学者是无关紧要的，这大大降低了你的上手/学习及改造成本。
- 易于升级： 对于一些配置优化和完善，升级只需要改改 Starter 版本号，不需要你再照着最新版疯狂复制代码，减少你出错的概率，提升你升级的效率。
- ...
总之，我们希望更多人多多反馈，一起完善。有技术的捧个技术场，有人的捧个人场，有钱的捧个钱场。
ContiNew 能二开开源吗？
非常欢迎在遵守对应项目开源协议的基础上进行二次开发开源，扩展生态系统。
Creator 接定制开发吗？
Creator 仅在业余时间维护开源项目，有单独全职工作，不承接定制开发。如有需要，可协助各位老板在维护群或交流群内发送广告。Coder help coder.