win301

曾经开发过一个比较复杂的系统，功能很多，项目组 5 个人，开发了约 1 年时间，最终项目完成后，大概有 800+类文件（我相信很多人看到这个类文件的数量可能都会想着应该将项目模块化拆分，我在这里不做过多讨论，就先假设项目组没有多余时间来做），每次使用 Maven 打包，需要耗时 2 分 20 秒左右，这已经是优化过一轮后的结果，在优化前大约 3 分 40 秒左右，我想着这样可不行，能不能有其他构建工具能提高项目的打包速度呢？以前就看过 Android 的同事在用 gradle 来打包，我想着后端项目理论上也应该可以打包，原理差不多，然后就去官网看了教程，然后开始研究 Maven 项目转换 Gradle ，通过 gradle 提供的命令行工具转换完成后，迫不及待的试试进行打包操作，然后神奇的事情发生了，这个项目打包成 jar 文件只用了 9 秒钟，虽然打包前还需要改一些打包所需要的代码，但最终的代价是值得的，以后所有项目就都用 Gradle 了

@cMoon 你这相当于是面向数据库编程了，这 b 表和 c 表如果以后还会被其他表关联，你打算怎么做？继续通过继承，然后继续 excludeProperty 无关字段？（假设 excludeProperty 能实现你的想法），建议你复习一下或者重新学习一下面向对象编程有五个基本原则。

绝大部分开发者不会用你这个思路来使用 ORM 框架，所以也不会碰到你的问题
说个正常的或者通常情况下使用 ORM 框架的思路
给这 3 个表分别建立 3 个 entity ，3 个 mapper ，然后你再任意 serviceImpl 类里，随意封装数据结构即可
就是有几百个表都有你说的情况，也都按照这个模式来做，这样即便某些表修改了字段增删了字段，在代码层面的改动会非常小，也很容易改

你可能还在学习阶段，所以才会问出这样的问题来，之所以封装一层 Service ，是因为操作 DB 也就是 Mapper 层，还需要做一些额外的工作才能完成的更好，你可以看下 ServiceImpl 这个类里，都干了什么，而且 ServiceImpl 类是通过继承来实现功能的，并不算是严格意义上的一层，只能算增强，如果你不想用，也可以在你自己的实现类里不要继承 ServiceImpl ，值注入 Mapper 就好

hutool 非常好用,别听这些鄙视链的人瞎说，维护非常频繁，看楼上很多人说某些功能 可能有 bug ，这在软件行业多正常的事情啊，强如 spring ，你们自己去 GitHub 上看，有多少人提 Issues ，以及每次发版列出的 releases 的改动有多少 bug 修复，好家伙我都服了，免费用人家的开发成果，结果还跳出来吐槽别人，你们这是什么精神？

@jacketsmith10 那其他人正常吗？当你遭遇诡异时，如果各种尝试无果后，就应该果断选择看看其他人的环境下是否正常，利用排除法来解决问题，如果其他人都正常，那就是你的环境有问题了，可以考虑重新初始化一下各阶段的环境，如果其他人也有问题，那大家一起想办法和你一个人苦思，效率截然不同，而且有很大概率，其他人已经遭遇过这个问题，他只需要花费 2 分钟告诉你怎么解决这个问题。

@bhbhxy 哈哈，按照你的说法，任何语言在开发之前都需要进行一些配置的，这并不是 Java 独有的，而且 up 碰到的问题，其实并不常见，就因为个例就能让你得出一个 “公司让转 JAVA 我极力拒绝”，那你可能就是在给自己找心理安慰的理由而已。

https://www.jetbrains.com/zh-cn/idea/nextversion/#section=mac
试试 idea 的目前正在开发的测试版本呢？

没碰到过你说的这种情况，你可以用排除法，把 jitpack.io 这个 repository 块的配置去掉，然后试试看，是不是依赖包本身就无法从你公司的私服下载？
还有就是如果 https://www.jitpack.io 很慢，那直接舍弃掉换一个远程仓库不行吗？比如
<repository>
<id>central</id>
<url>https://repo1.maven.org/maven2</url>
</repository>

这是 maven 中央仓库，在国内也是可以访问的，速度还不错，当然了跟阿里云是肯定无法比的，但贵在 jar 包很全面，而且很及时，新出的 jar ，这里很快就会更新，阿里云一般会慢 1 到 7 天不等的时间

还有就是你本地使用的 maven 客户端的版本是什么，也可以升级一下，目前最新版本是 3.9.2 ，你检查一下