maven出现之前的样子
本文目的
最近公司来了几个新入行的小伙伴，因为不理解maven是干嘛的。一方面，也是自己开始做starter包，需要重新学习回顾下maven 的知识(《maven实战》)，另一方面，也将自己学习的东西能够跟大家分享。后边的几篇相关文章，可能会有理解不对的地方，希望大家指正。
因此这篇文章主要是回顾下，maven这类工具出现的由来和必要。
正篇
1. jar包的形成过程
maven的作用，我们最熟知就是依赖管理，也就是帮助我们在项目里，引用jar包，那就从jar包说起。
众所周知，jar包即其他公司封装对外提供的工具包。以前一个jar包的形成到推广到社区，并被大家认可应用的过程，我理解的话，这个过程可以拆分为经验沉淀、封装工具、封装jar包、对外开源四个阶段，如下图：
上图示例，是一个专门做OA系统的公司，因为公司业务驱使，工程师可能就会在excel处理方面，遇到的问题比较多，优秀工程师一路对excel处理方法抽离业务，不断迭代优化，最终大概按照以上步骤，渐渐成了公司最突出的技能，封装jar包，并在公司官网开源。
下边具体拆解这几个步骤，比较简单。
1.1 经验沉淀
每个公司有不同的业务方向，开发的工程师就会有不一样的开发任务，在编码过程中，基于实践，优秀的工程师总结出高可靠、高效率的代码块，帮助自己在工作中脱颖而出。
1.2 封装工具
优质的代码块经过分享后，慢慢被项目组成员认可并应用，集思广益形成工具，在项目组内大量使用。
当使用的场景越来越多，该工具开始暴露出或多或少的bug，为了满足遇到的这些场景，项目组里的优秀工程师又进行多次优化，形成更加健壮、优秀的工具。
1.3 形成jar包
优秀的工具渐渐被公司其他项目组认可，因此，在公司技术升级时，会被选做基础框架中的工具，专人维护，形成jar包，对外不可变。
1.4 对外开源
当公司发展到一定程度，为了提高自己在行业中的地位及影响力，开始做技术交流，参加各种论坛，并对外分享一些好的工具包。
2. 问题暴露
公司都在发展，很多公司都想成为主角，开源自己的技能。那渐渐网络上的jar包就非常的繁杂，渐渐也暴露出了越来越多的问题。
2.1 寻找依赖包繁琐
在maven等管理工具出现之前，往往搭建公司项目框架，非常繁琐，当需要spring framework依赖的时候，大家会去spring framework官网上寻找，当用log4j依赖的时候，大家又要去log4j官网上找。
各个官网风格迥异，位置不一样，那就需要花费很多时间去为项目收集jar包。对于一些网上资源比较少的jar包，我们可能需要更多的时间去收集。
必要的时候，我们会把一些比较少见的jar包当做资源收藏起来，方便以后应用。
2.2 源代码繁重冗余
项目引用的所有jar包需要放到项目中的某个目录下，并和源代码一起提交到代码仓库保存，造成项目占用空间大。
多个项目工程下存在相同的依赖jar包，jar包冗余重复度高。
2.3 依赖升级麻烦
就算对于那些不断在升级的依赖包（shiro的漏洞解决、优化），尤其存在依赖关系，同时升级的那种，就会都要对应升级的。
2.4 管理复杂
随着公司越来越大，职责分工越来越清晰，核心开发和业务开发的无法完全分离，存在重复依赖，父子结构项目开发几乎不可能。而清理、编译、单元测试、构建、打包等操作，都需要手工操作。
3. Maven出现
基于以上的问题，依赖管理、构建管理、项目管理工具需求呼声逐渐增多，渐渐的出现了很多解决方案。maven是其中一个比较好的。
在maven出现之前，还有其他构建方案，IDE、Make、Ant等，我们接触过的，估计也就是IDE，现在诸如Eclipse、Idea等开发工具，也集成了maven，能够很好的应用maven插件。
当然，现在也有Gradle，并且据说Gradle已经是springboot 2.3版本优先使用的默认构建工具。springboot也针对这个问题做出了解释，我反正没看明白，我理解可能他们意思就俩个优点，比Maven快、看起来比Maven更顺眼。
但是springboot也给出了最后的建议。If you’re a happy Maven user, please continue using and supporting the tool that’s working well for you。我不是一个快乐的maven使用用户，只不过我习惯了而已。
尽管以后可能推荐使用Gradle，除非是新公司，那可以顺着推荐的走，像我们公司已经做了很多的产品，都是用的Maven，如果在新框架中换成另一个构建工具，那大家又要花时间学习新的东西，还要切换脑力维护老项目。我想，我们还是安稳的使用Maven吧。
下一篇回顾下maven的一些主要概念。仓库、坐标。maven的基本概念介绍