写在前面
三四年后，从头开始，重新改造 IGV。或许听起来有点奇怪，毕竟几年前就整完也可用的项目，为什么要重新改造？原因有二：
- 支持高清屏，之前的版本依赖JDK8，后续需要支持高清屏
- 优化逻辑，尽管原有逻辑应该挺好
- 以前的改过了，其实除了支持 sRNA 数据查看外，还改动了别的地方，这次不改
总而言之，就是重新来过。于是碰到不少坑。
1. 只能 JDK11 ，甚至是特定版本
fork 然后 pull 了 IGV 的最新项目，尝试 gradle 构建。怎么整都构建失败。测试来回，发现 jdk8 肯定不行，而 jdk17 也不行，所以只能 jdk 11。说实话，很诡异。但或许是 gradle 的问题？
2. 加载本地 jar 包方式麻烦
不像 Ant 或者 Maven 项目，这两者比较简单。逻辑上对于 Ant 项目，直接导入就行可；对于 Maven 项目，我们直接开个 CMD ，导入本地库到 Maven 仓库也就没什么事了。
对于 Gradle，我就觉得很麻烦，当然现在看来跟 Maven 有点像。
本地 Lib 最简单的注入方式是：
fileTree(dir: 'lib', include: '*.jar')
这个操作会有一点问题，也就是会把整个 lib 目录下所有库装载进去。
事实上，应该也可以指定到具体jar名字。
后来我发现，其实可以跟 Maven 类似，写成本地库。具体是修改，补充本地库寻找目录
repositories {
mavenCentral()
// add local database
flatDir { dirs 'lib' }
}
随后，按照其他在线库方式装载
[group: 'com.jidesoft', name: 'jide-common',version: '3.7.3'],
[group: 'toolsKit', name: 'toolsKit'],
[group: 'TBtoolsSrc', name: 'TBtoolsSrc'],
这样就搞定了吗？事实上，都没有，你还要得专门针对每一个导入，修改
Module-info.java
基本这样就完成了导入。说实话，真的折腾。
3. exclude排包粒度就到 jar，无法排除 Jar 下面的类
很多时候，我习惯性将一个项目打包成一个Fatjar，这个本身是没问题的，毕竟包含了所有依赖。但是问题来了。假设现在有两个 Fatjar，他们内部都有 toolsKit 这些类。（这个问题在 Ant 项目或者 Maven 项目，其实没啥问题，他会自动优先加载，或者随机加载？某一个）。在 Gradle 构建中，他就不行，就一定要你处理。
这里先看看目录结构
于是，说实话，找了老铁帮看，一起整了大半天（对我来说，整整24+小时），最后基本是认怂。
可以说，这个 Gradle 他就只能以 Jar 包为单位来排除。比如，
可以看到，其实对于这个
org.apache.commons，他只是一个大的分组，或者认为是组织结构。其实每一个模块对应的是一个 Jar 文件。所以排除依赖冲突，直接排除的是commons-jexl-2.1.1.jar以及commons-lang3-3.9.jar这类 jar 文件，而不是 jar 文件中的某些类。
至此....问题基本解决。
至于解决办法，那就是不要导入Fatjar，直接按照不同的‘dist’和对应‘lib’依赖的方式导入。另外，或许以后要考虑路径分组编写，等等....
4. 补充：待导入的 Jar 名字不能太复杂
比如 TBtools_JRE1.6.jar 这类名字，会出现一些识别问题，最好是简化为 TBtools-JRE-1.6.jar 或者直接 TBtools.jar，一般就没啥事了。
写在最后
时间是一个问题。现在越来越觉得，每个人的时间精力有限。说实话，花了一天多时间，说学到东西，提升了？是的，那肯定是知道一些东西，也有一点提升；但如果说这个提升，或者这个踩坑是否对自己有帮助，我想可能影响不大。因为很多时候，这些小的知识点，对于实际生活或者工作需要，应该是完全用不上。
你会不断告诉自己“这个需要搞定”同时是“这个很不值得”。在这个痛苦中煎熬，同时你会想起来，还有不少事情正等着你去完成。这是一个非常复杂的事情。我想，如果经历更多，那么应该是开始怀疑人生。
这其实不是一个好事。
网友评论