maven 的代码仓库分为 2 种类。 这 2 种分别为 snapshot 和 release。 作用和区别 可以将 release 理解为稳定的发布版本，当版本 release 后，如果你发现你的代码有问题，希望马上进行修改的话，一般来说是不可以的。 代码仓库通常不允许你将 release 版本多次发布，如果你需要进行再次发布的话，你需要修改版本号。 snapshot 针对 release 来理解的话，最简单的说法就是可以多次发布，如果你愿意，你可以将任何字符修改一下，然后发布上去。使用 snapshot 发布的时候的代码库，多次发布是不会被拒绝的。 约定 版本号中的 release 和 snapshot 区别就是，snapshot 是在版本号后面添加 -SNAPSHOT 字符。 这几个字符必须是大写，同时这几个字符不能变，添加在版本号的后面，中间使用分隔符进行分隔。 例如我们有一个项目，项目中的的依赖定义为： <groupId>com.ossez</groupId> <artifactId>parent-modules</artifactId> <version>0.0.1</version> <packaging>pom</packaging> 如果是 SNAPSHOT 版本的话，那么version 部分就需要修改为 <version>0.0.1-SNAPSHOT</version> 而且只能是这种格式。 Maven 使用 我们知道 Maven 在本地是进行缓存的，如果你使用的是 release 版本的话，一旦包被下载到本地了，Maven 是不会重新下载的。 如果你希望重新下载的话，你需要手动删除本地中的缓存。 如果你使用的是 SNAPSHOT 版本的话，每次在构建的时候都会从定义的新仓库中下载新的版本。 这样就更加方便项目小组之间的协调。 比如说，项目小组 A 有个包的版本为 0.0.1-SNAPSHOT ，项目小组 B 中有个包是依赖于这个的，但是项目小组 B 发现这个包中有问题，需要进行修改。 小组 B 将会通知小组 A 进行修改，小组 A 修改完成后将会 Push 到仓库中，尽管版本号没有变，那么项目小组 B 在编译的时候，也会使用新推送的 0.0.1-SNAPSHOT 版本。 那么小组 B 依赖小组 A 修复的错误就已经修改完成了。 如果采用 release 的话，那就必须修改版本号了。     在持续集成的时候，过于频繁的修改版本号并不是一个非常好的实践，这将会导致过多，过于频繁的版本号变化。     上面的图片显示了我们推送到中央仓库中的 SNAPSHOT 版本，这个版本将会随时因为被修改而更新。 https://www.ossez.com/t/maven-release-snapshot/13437

错误提示的信息如下： By default, the Java language level is set to 5 which is not supported by the current Java version. Update the language level to 6+.Update source level in codebank     问题和原因 这是因为很有可能在你的 maven 配置 POM 的时候的编译插件 maven-compiler-plugin 的版本。 通常这个插件的默认版本都比较低。 如果你使用的是 3.7.0 的话，那么默认使用的是 Java 1.5 的 Level。 如果你修改使用最新的 3.8.1 的话，那么将会默认使用 1.8 的 Level。 目前，我们应该会使用 JDK 8 或者 11，因此你需要手动进行一下设置。 设置有 2 个方法。 第一个方法就是添加下面的参数到属性中。 <properties> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties> 第二个方法就是直接指派到插件的 config 配置中。 如下面的配置参数。 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.1</version> <configuration> <source>1.8</source> <target>1.8</target> </configuration> </plugin> JDK 9 及其后续版本 从 maven-compiler-plugin 插件的 3.6 后续版本开始，添加了一个 release 的配置。 如果你使用 JDK 11 的话，你可以使用下面的配置。 <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.1</version> <configuration> <release>11</release> </configuration> </plugin> 使用上面的配置结果将会能够更好的适配 JDK 11 版本。 https://www.ossez.com/t/intellij-idea-java-level/13436

根据官方链接中的说明： Apache Maven - The Central Repository Documentation (sonatype.org) 从 2021年 2 月开始，将会使用仓库地址为： https://s01.oss.sonatype.org 上面的意思是，如果你的项目是在 2021年02 月之前提交到 OSSRH 中的话，那么你需要使用的提交地址为：https://oss.sonatype.org/。 否则，你将会需要使用新的地址为：https://s01.oss.sonatype.org/     时间的终止点为 2021年02 月。 这个在你具体申请提交的时候会被提示到。   https://www.ossez.com/t/ossrh/13429

小龙虾当前价格表（2021-04-11 - 2021-04-18） 鲜活价格 本周的鲜活小龙虾价格表。 Item 单价 备注 （大）鲜活小龙虾 $6.99 /LB （中）鲜活小龙虾 $5.99 /LB （小）鲜活小龙虾 $4.99 /LB Cooked 小龙虾 我们也可以提供 Cooked 的小龙虾。 Cooked 的小龙虾，可以预定 3 种口味：麻辣 /13 香/ 蒜香。当您下单的时候，请联系群主辣度，如果没有说明的话，我们默认做成中辣。 Item 价格 备注 大份 $33.99 6LB 中份 $25.99 4LB 小份 $16.99 2LB 送货 本周我们可以免费送货提货点：Nashua Costco，Before Whole Food，N Londonderry Bus Station。

这几个单词在前端开发的时候可能会经常遇到。 因项目需要，琢磨了几天 angular，结果下来还是有点一脸懵逼。尝试进行编译下简体中文的文档也是一堆错误。 感觉最最糟糕的就是下载相关的模块，这个太令人难受了。 随手就顺便研究下了上面几个名词了。 Angular 和 AngularJS 虽然名字大部分相同，但是这 2 个东西完全不是同一种动物。 在 Angular 1 的版本的时候，我们可以认为 Angular 就是 AngularJS，一种类似 Jquery 的库。通常可以使用这个库导入到项目中，然后通过项目来完成后端的 API 调用等数据处理逻辑。 从 Angular 2 开始，Google 几乎重新了 Angular， Angular 2 可以认为是一个独立的框架而将 AngularJS 独立出来了。 当前 Angular 的版本是 11.2。 使用 Angular 的目的就是使用这一个已经集成了AngularJS 的框架，可以在不需要后端程序的情况下直接对数据进行获取和处理。 等于针对一个项目，可以使用 Angular 完成所有的数据流程。 正是因为这样，Angular 将会打包进来很多可能前端需要的数据处理包，结果感觉就是导致 Angular 比较臃肿，很多不需要的东西都全部打包进来了。 在使用 Angular 框架进行编译后，将会生成一个可以在 nodejs 服务器上运行的代码，并且将上面的代码部署到 nodejs 服务器上，以便于做到前端和后端的分离。 AngularJS 和 reactJS 虽然 reactJS 并不被称为是 reactJS，通常使用的名称为 react。 如果使用上面的对比应该是合适的，通常这个库比较小，通过在前端页面中导入这个 JS 库，能够实现前端的很多功能和后端的通信。 因为不是简单，代码量少，在近年使用的趋势是越来越大。 学习曲线 从学习曲线来说，个人的感觉 Angular 学习曲线明显高于 reactJS。 这个其实也很正常，因为 Angular 不仅仅是应 JS 库了，是一整套前端的框架，这套框架比较复杂，同时还使用了 TS 为开发语言。 在前端选型中，我们通常会通过一些搜索，GitHub 的使用量来进行判断。 针对技术方案来说，用的人越多，说明越受欢迎。     通过访问下面的链接： angular vs react vs vue vs @angular/core | npm trends 来查看 npm 的趋势，应该为很多人在前端的选型方便提供一个参考。   https://www.ossez.com/t/angular-angularjs-react/13425

搜索引擎都是各大浏览器竞争的入口之一。 微软也不例外，在新版的 Edge 浏览器中使用的默认是 Bing 搜索引擎，大家都知道这个 Bing 搜索的功能实在是没有办法恭维。 很多人都会尝试修改为其他的搜索引擎，比如说 Google。 下面的步骤就是能让你修改默认的地址栏搜索引擎为 Google。 在 Edge 中，地址栏默认使用的路径为服务。 打开你的 Edge 浏览器，在右上角上面的 … 中选择 设置。 Services 在弹出的界面中，选择第二个选项，隐私，搜索和服务。 在页面的最下端，有一个选项是地址栏和搜索。单击这个选项。 在后续的界面中，可以看到地址栏使用的搜索引擎。 在这里你可以选项你需要的搜索引擎即可。 浏览器的默认搜索引擎入口，都是各大厂商竞争的焦点之一，因为只有掌握了用户的入口才能掌握后续的服务。 微软近年在浏览器上面动作频频，Edge 浏览器确实也有了不少的提升。 Firefox 和 Chrome 诟病的内存消耗过高的问题，在 Edge 中也有了些改进。 https://www.ossez.com/t/edge/13424

Visual Studio Code 因为相对小巧和扩展性，使用的人越来越多。 很多聪明的孩子总是不安于现状，Git 代码管理目前已经几乎是标准配置了，但是 VSCode 针对 Git 部分的配置总是感觉很弱鸡。 现隆重介绍下GitLens 插件，超过 8百万的下载量，可见欢迎程度。 安装 在市场中，直接搜索 git，出现的前面几个就是你需要的。     在弹出的界面中进行安装即可。 当你的 VSCode 左侧出现有上面显示的图标后，显示 GitLens 已经安装成功了。     当你第一次进入的时候，将会提示进行设置。 这个时候，你使用默认设置即可。     边栏丢失问题 有时候你可能会遇到左侧边栏丢失的情况。 这是因为设置中默认使用了 VSCode 的代码视图。 可以进行下面的修改，输入，打开 GitLens 的设置。     然后找到视图，在视图中选择 GITLENS LAYOUT 的配置。 在完成上面的配置后，你就可以重新在左侧看到 GitLens 的边栏了。     上面的配置选择后，将会在左侧边栏下面添加一个 GitLens 的快捷使用对话框。 https://www.ossez.com/t/vscode-gitlens/13423

Visual Studio Code 因为相对小巧和扩展性，已经迅速占领了不少的开发市场，尤其是前端。 但是 Visual Studio Code 自带的 Git 工具却比较弱，因此很多人都开始使用一些扩展的 Git 工具。 现在介绍的扩展工具名为 Git History， 在 Visual Studio Code 上将近 4 百万的下载量，可以通过这个了解到这个工具受欢迎的程度。 安装 在 Visual Studio Code 上搜索 Git ，出现的第一个就是我们需要安装的插件。 在出现的屏幕中，单击安装来进行安装。 如何使用 在你选择查看的文件后，单击键盘上面的 F1，在弹出的窗口中，输入 Git View History 当输入回车后，将会在界面中的右侧显示当前文件的提交历史。 通过这个操作能够更好的了解当前文件的历史情况和修改情况。 当然，你也可以使用快捷键 Alt + H。 https://www.ossez.com/t/visual-studio-code-git-history/13422

早就知道 ITeye 是需要关闭了，因为 CSDN 没有必要维护 2 套博客系统。 并且很多人应该早就收到电子邮件说是所有文章合并到 CSDN 上了。 但是今天登录后看到这样的界面，还是有一点点感慨。     博客生态圈早就不再了，现在已经是快餐文化和直播文化了。 随着博客的陆续关闭，真正可以看到的优质内容已经不多了。其实这也没有什么只是时代的发展而已。 但是真的走到这一天的时候还是有点不舍，毕竟很多人的开发生涯都是从 20 多年前的 Java 开始的，现在框架也越来越多，人貌似也越来越浮躁了。 其实应该说是区域稳定了，计算机技术本身就为了生产服务的，生产服务的话需要的是信息技术和产出的，只需要提供相关的服务就可以了。 不管怎么样，在 JavaEye 上应该很多人也留下过足迹。 以此怀念。 https://www.ossez.com/t/javaeye/13421

默认分支在 GitHub 中比较重要，通常默认分支能够确定你检出的分支在那个分支上面。 在 GitHub 中是可以对默认分支进行修改的。 选择 GitHub 中的设置     然后在设置后的选择中，选择分支。 在接下来的界面中，选择分支切换按钮，然后在弹出的界面中选择需要选择默认的分支名称。 通过这个选择可以将仓库的默认分支进行切换。     当完成上面的默认分支切换后，选择更新就可以完成默认分支的选择了。     至此，从仓库中克隆的结果将会使用新的默认分支，你获得的代码将会默认的分支中的内容。 https://www.ossez.com/t/github/13420