啊，最近的重心从上线那个web干儿子项目转移到强身健体上了。但身体这种东西，得慢慢来，不能说一口吃个大胖子。问题是，预算给着呢，但是浑身酸痛的时候总不能进一步加大锻炼规模。于是乎就能享受一段平静的生活……
回想起年轻的时候，会不厌其烦的定期升级应用，为了一个新的功能试用beta版本。总觉得，新的东西会带来改进，会有更好的体验，会进步。但后来呢，总算了解到保守和因循守旧的魅力。
虽然只是可能不到一年？但是看上去现在和那个时候区别真是大啊，至少在面对新鲜事物上的态度是有很大区别的。那个时候，我成为了nexus用户，目的是在上传各种自己的底层库的包，并且能随时下载较早版本的包。还希望能实现应用的包管理（虽然这个最近才实现……）。然后我就选择了nexus3，故事也就是从这里开始……
首先，nexus3有更人性化的界面和……，可能也就只有界面好看些？啊不能这么说，应该是说“更多的功能有待我发现”
如何自动删除超过两年的老包？
作为一个穷苦大众，没有那么多硬盘资源，毕竟10G都要1刀。一个包小则10m多则30m，然后在小步提交，自动发布。这种种压力下，我当然是选择原谅他啊。于是最近我把nexus迁到家里的服务器了，1T硬盘随便玩。但“最近”之前的日子，我还是必须要自动删包的。
方案一：定时任务
思路很简单，也是一上来就会想到的方法。起个定时任务，把老包筛出来，然后全部删掉。
于是我搜到这篇文章Can I delete releases from Nexus after they have been published?：
If you decide that you do want to remove old releases Nexus makes this easy. As of version 2.5 there is a new task you can add, "Remove Releases From Repository".
This scheduled task allows you to trigger the deletion of release components, supporting these use cases and taking care of meta data updates and removing the need to manually delete the components or use an external system to trigger the deletion.
我当时就觉得稳了，这个配一下就好了。然后高高兴兴的跑到我的nexus上，试着搞一个定时任务去删包，结果根本没有什么remove release之类的。我大概就看到了这么些个东西。
nexus 3的task.mmp
稍微沾点边的，“purge unused components and assets”，“purge unused Maven snapshot versions”，“remove snapshot from maven repository”。snapshot的问题我们稍后再说，反正到现在一些临时的包仍然没能放到snapshot里。但第一个其实看上去还是很有吸引力的，点进去之后就是这么一番景象。
create task.mmp
然后我起了个名字，填了个30天，每周检查一次。就在这个时候，我想选repository的时候发现，只有maven-central和一个奇怪的代理。文档上是这么说的(https://books.sonatype.com/nexus-book/3.0/reference/admin.html)：
This task can be used to remove components and assets in proxy repositories. Any component that has not been requested in the configured number of days will be purged.
我跟你讲，我当时脑子里就是这么个调调：“我要这铁棒有何用？我有这变化又如何？”我自己的包，当然不是传proxy的库啊，肯定是传host的库啊。
到此，我大概想通前面那个Can I delete releases from Nexus after they have been published?上第一句话，Releases are forever, right?
方案一搁置，因为其实可以出发脚本用脚本删……
方案二：自己写个脚本，定时删一波
和方案一最后说的脚本不一样，方案一的脚本是定时任务里的脚本，好像只支持groovy。这里说的，是独立于nexus，自己发请求拿到包列表，然后一个个看时间。
由于工作原因，虽然我个人是懒得写的，但是正好工作上也遇到了这个问题，我就做出了这么一个大胆的尝试，不同的是工作中遇到的是nexus2，我是nexus3。
当时经历了方案一的震惊、失望、疑虑、恐惧之后，我已经不再是从前的我了，这次我留了一个心眼。我打开浏览器，打开了两个nexus，然后打开了nexus2的包列表的页面的开发者工具，又打开了nexus3的包列表的页面的开发者工具，然后显而易见的，两个脚本不能一起写，因为页面结构完全不一样。
方案二的结局还算好，反正nexus2的我是写了……nexus3的，我觉得我还是用方案三抢救一下吧。
方案三：迁到家里+端口映射
之后这个问题就再也没有解决，直到最近迁到了家里的服务器，1T硬盘，随便传，传的满我就手工删一波。
结论：
为什么当初不搞个nexus2呢？
我想用snapshot
由于网络环境日趋复杂，我的网络结构也日趋扭曲，导致我的部署流程日趋复杂。大概就是复杂到了我普遍采用Jenkinsfile做部署pipeline的地步。然后我现在的需求是传snapshot，然后部署到测试环境，然后等到那天硬盘不够了就直接删blob stores，或者跑那个定时任务，清理snapshot就好。
然后我就兴高采烈的建了一个snapshot的库，然后传上去一看，大概就是这么个景象：
snapshot.mmp
我给的版本是死版本1.0，然后包名叫做LadderInfoServer，然后group是xlo。但是后面那一串日期简直……
所以我的需求就很简单，拿到snapshot里对应版本的最新或者最后一个包。翻译一下就是，因为一个版本可以有n多snapshot，我希望拿到最新的那个。
我跟你讲， sonatype的文档和支持还是不错的，我就搜到了这个How can I retrieve a snapshot if I don't know the exact filename?：
A. Nexus Provides a separate REST API to retrieve files when interpreting the maven-metadata.xml is required. The syntax looks like this:
wget "http://repository.sonatype.org/service/local/artifact/maven/content?r=snapshots&g=org.sonatype.nexus&a=nexus-utils&v=LATEST" --content-disposition
Where:
r = the id of the repository or group to search (Required)
g = the groupId of the file (Required)
a = the artifactId of the file (Required)
v = the version of the file, this may be "LATEST", "RELEASE", a version number like "2.0", or a snapshot version number like "2.0-SNAPSHOT". (Required)
c = the classifier of the file (Optional)
e = the type or extension of the file (Optional)
p = packaging (Nexus will resolve known packaging types to the correct extension). (Optional)
就相当的靠谱是不？但遗憾的是，这个support是针对nexus2的，nexus3没有这个API。我跟你讲，我脑子里面又是那个：“我要这铁棒有何用？我有这变化又如何？”
结论：
我为什么当初不搞个nexus2呢？
怎么说呢不是说nexus3这两个设定有什么不对。比如说没有task去删host的包，其实我们从nexus2的文档里就看到了理由。因为他仓库类型就release或者snapshot（当然还有一个混合），你如果不是snapshot，那就是release，那既然release出去了，就没有收回来的道理啊。
snapshot那个我就不知道了，不是很懂为什么没有这个API了。我没有调查过nexus2，但是nexus3每个版本里都有个maven-metadata.xml。里面有各种信息，可以让你拿到最新的包，但是就有点繁琐了，GitHub上也有库写了这个脚本。
总的来说，就是人家想法没啥毛病，似乎是在做“对的事情”。但是遗憾的是，当我面对我的的场景、我的需求的时候，对的事情只有一种，那就是简单轻巧的解决我的问题。极端的说，我希望能在主页上有一个自动删旧包的绿色通道，点一下就搞定。现实的说，nexus2更加符合我的需求，虽然我做了一件“错的事”，我删除了release出去的东西。
问题的关键在于，什么是对的事情？年轻的时候我认为，对的就是对的，错的就是错的，如果一个东西的概念本身是这样，那他的实现就应该和概念完全一致。而作为开发，需要做的就是正确的理解概念，然后翻译成代码就好了。现在嘛，经历了很多事情，见到了更多的人、更多的事。
为什么要写代码呢？除了所谓的兴趣之外，为什么要写代码呢？因为需求，有问题需要解决，我们需要某种产品或者业务逻辑上线。如果说，写出来的代码完全不能解决人民群众生产生活中的问题，那这个代码根本就是废代码。这样的代码即使设计再好，技术实现再先进，再易维护，在我现在看来还不如直接命名a、b、c来的好。
什么是对的事情？最大价值就是对的事情。要么对自己有价值，要么对别人有价值，要么对社会有价值。我自己的价值和别人的价值我不知道，但社会的价值在我有限的认识里就是钱，或者社会资源。所以我对我之前全面弃用JenkinsFile和对nexus3的不满都只有一个原因，因为这两个东西不符合我的价值，而我的目前的所有应用和工具都只为我自己有价值。但最近由于做了一些网络调整，部署流程变得复杂之后，JenkinsFile立刻就成了比传统配置廉价的多的解决方案，然后立刻就全面采用了。
毫无疑问，之前的那个网站项目由于是干儿子，一切从简，维护不了就弃坑的边角项目，不写哪怕一行测试才是正确的事情。
年轻的时候，总是觉得新的东西最好；老了才发现，稳才是最好的。
会不会Android开发？会！学不学kotlin?不学，还没彻底普及！
会不会IOS开发？会一点！学不学swift？不学，天天更新稳定再说！
gradle熟不熟？还行！用不用deploy传包？不用，这玩意域名解析存疑！
知不知道concourse？知道！要不要更新pipeline？不更，发个邮件都要第三方！
react好不好？好！要不要用？用啊，就这个来的快。
流行？趋势？在我还年轻的时候，我会觉得这很好。现在想来，既然是趋势，就说明根本没有普及，或者说没有得到验证。既然是流行，那明天这个流行会不会过去？如果不是经过仔细的权衡利弊就采用一个技术，那如果用到半路发现坑，跳车都来不及。
当然，在这里，还是要向半路发现坑，然后自己填了去提pr的人。有了这些好人，才有众多免费的工具。但是，这个世界上还是好人多。那我还是做一个使用者比较划算。
也许过几个月又会觉得现在的我年轻，竟然还会去看这些东西。
网友评论