Second Week(补充完整)

 Blog:

1.introdution of Version Control/Git,SVN

2.introduction of Build Tool/Maven,Gradle

3.Analysis of container and injection in java ,their history and future

Practice

1.Git-Install and practice

2.Maven-install and practice

3.Glassfish server installation and startup

4.Java EE Tutarial Example-Hello1

一、introdution of Version Control：Git,SVN

     版本控制系统（version control system）,是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。版本控制系统不仅可以应用于软件源代码的文本文件，而且可以对任何类型的文件进行版本控制。用的比较多的如svn，git等。

   为了让不同系统上的开发者能够协同工作，集中化的版本控制系统应运而生（CVCS）。这类系统都有一个单一的集中管理的服务器，保存所有文件的修订版本。而协同工作的人们都通过客户端连接到这台服务器，获取最新的文件或者提交更新。集中化的版本控制系统，最显而易见的缺点是中央服务器的单点故障问题。如果宕机，那么就会出现谁都无法提交更新的情况，那么也就无法协同工作；如果磁盘发生故障，而备份又不够即时，那么就有丢失数据的风险，最坏的情况是丢失整个项目的历史更改记录。因此，分布式版本控制系统问世了（DVCS）。

   在分布式版本控制系统中，客户端不仅仅是只提取最新版本的文件快照，而是把代码仓库完整的镜像下来。所以每一次提取的操作，都是对代码仓库的完整备份，因此也就不必担心协同工作用的服务器发生故障。

   Git和其他版本控制系统的主要差别在于：Git只关心文件数据的整体是否发生了变化，而多数的其他系统则只关心文件内容的具体差异，它们在每个版本中记录着各个文件的具体差异。在Git中的绝大多数操作都只需要访问本地文件和资源，不需要联网。这是因为Git在本地磁盘上就保留着所有当前项目的历史更新，所以处理起来速度飞快，这是使用空间换时间的处理方式。使用Git，即使在没有网络或VPN的情况下，你同样可以非常愉快的频繁提交更新，等到有了网络的时候再提交到远程的仓库。

 

 

GIT:

分布式相比于集中式的最大区别在于开发者可以提交到本地，每个开发者通过克隆（git clone），在本地机器上拷贝一个完整的Git仓库。下图是经典的git开发过程

 

 

Git的功能特性：

从一般开发者的角度来看，git有以下功能：

1、从服务器上克隆完整的Git仓库（包括代码和版本信息）到单机上。

2、在自己的机器上根据不同的开发目的，创建分支，修改代码。

3、在单机上自己创建的分支上提交代码。

4、在单机上合并分支。

5、把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。

6、生成补丁（patch），把补丁发送给主开发者。

7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。

8、一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。

 

 

从主开发者的角度（假设主开发者不用开发代码）看，git有以下功能：

1、查看邮件或者通过其它方式查看一般开发者的提交状态。

2、打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。

3、向公共服务器提交结果，然后通知所有开发人员。

优点：

适合分布式开发，强调个体。

公共服务器压力和数据量都不会太大。

速度快、灵活。

任意两个开发者之间可以很容易的解决冲突。

离线工作。

缺点：

资料少（起码中文资料很少）。

学习周期相对而言比较长。

不符合常规思维。

代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

 

 

SVN：

 

缺点

1、服务器压力太大，数据库容量暴增。

2、如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。

3、不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。

 

优点

1、管理方便，逻辑明确，符合一般人思维习惯。

2、易于管理，集中式服务器更能保证安全性。

3、代码一致性非常高。

4、适合开发人数不多的项目开发。

5、大部分软件配置管理的大学教材都是使用svn和vss。

 

 

二、introduction of Build Tool/Maven,Gradle

 

 

Maven：

   Maven项目对象模型(POM)，可以通过一小段描述信息来管理项目的构建，报告和文档的项目管理工具软件。Maven 除了以程序构建能力为特色之外，还提供高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性，所以常常用两三行 Maven 构建脚本就可以构建简单的项目。由于 Maven 的面向项目的方法，许多 Apache Jakarta 项目发文时使用 Maven，而且公司项目采用 Maven 的比例在持续增长。

   Maven这个单词来自于意第绪语（犹太语），意为知识的积累，最初在Jakata Turbine项目中用来简化构建过程。当时有一些项目（有各自Ant build文件），仅有细微的差别，而JAR文件都由CVS来维护。于是希望有一种标准化的方式构建项目，一个清晰的方式定义项目的组成，一个容易的方式发布项目的信息，以及一种简单的方式在多个项目中共JARs。

 

gradle：

1.一种可切换的，像maven一样的基于约定的构建框架，却又从不锁住你（约定优于配置）

2. 强大的支持多工程的构建

3. 强大的依赖管理（基于Apache Ivy），提供最大的便利去构建你的工程

4. 全力支持已有的Maven或者Ivy仓库基础建设

5. 支持传递性依赖管理，在不需要远程仓库和pom.xml和ivy配置文件的前提下

6 基于groovy脚本构建，其build脚本使用groovy语言编写

7 具有广泛的领域模型支持你的构建

 三、Analysis of container and injection in java ,their history and future

1.container

   web容器是一种服务程序，在服务器一个端口就有一个提供相应服务的程序，而这个程序就是处理从客户端发出的请求，如JAVA中的Tomcat容器，ASP的IIS或PWS都是这样的容器。一个服务器可以有多个容器。

web容器部署面临两大挑战：

   不是所有企业都需要容器技术，还有不少web容器部署与管理的挑战需要面对，所以现在先缓缓也没有关系。web容器与相关技术正在为IT行业设下一颗超级炸弹。越来越多的技术开始支持容器部署模型，但我们仍处在游戏的初期。虽然web容器技术可以简化软件开发与部署，但仍旧有一些挑战需要解决。一些web容器相关软件已经准备接受生产验证，而其web容器他部分依旧在完善中。不是每个IT团队都能用上web容器；尤其是需要修改与调整流程来适应这项web容器技术。业务需要决定该技术是否对其有益，接着才衡量现有流程是否能与之匹配。

1.web容器部署场景

   web容器部署模型中有明确承诺，某些应用程序能从场景中获益。开发团队需要考虑创建web容器化应用程序或应用程序组件，因为web容器技术，如Docker可以简化流程。尽管如此，web容器应用程序需要新的开发方法，目前还没有被广泛采用。IT组织同样可以选择web容器化现有的应用程序。虽然这个方案可行，也并不是所有应用程序都适合这样操作。大部分web容器集群管理者依赖于无状态容器，意思是服务器X上的某个web容器挂了，你可以在服务器Y上启动新web容器。这对普通应用程序来说无法接受，除非web容器经过特殊设计可以动态横向扩展。虽然现在告诉IT员工数据中心是否会增加web容器管理员为时尚早，但看起来这个职责可能会被吸入现有的工作岗位中。开发者在web容器部署中扮演了十分重要的角色。现有的基础设施支持团队能够处理部署与管理。从另一面讲，web容器集群对大多数IT组织来说都是全新的概念，可能需要对不同的团队或成员进行扩充。

2.web容器并不是那么遥不可及

   数据中心采纳新技术的下一阶段挑战是围绕web容器的支持工具。容器意味着一系列新的数据中心配置文件——不仅仅是另外一种虚拟机。如果我们在操作系统级别比较物理与虚拟服务器，他们共享了许多相同的配置属性。有许多成熟的工具集可以同时管理这两者。web容器意味着完全不同的事物。我们无法在服务器或虚拟机级别管理应用程序；需要通过web容器内部进行管理。这个变化让基础设施管理团队从专注于管理应用程序，简化为集中精力管理web容器软件。虽然这被认为是一个好处，但也意味着web容器与管理工具存在间隙。web容器化后，网络管理与安全补丁都成为新的挑战。开发者创建镜像以及数据中心管理者需要对此承担全部或部分责任——目前仍有待观察。某些web容器集群管理套件可能可以解决一些基本问题。主流web容器部署需要面对的另一个挑战是，大多数管理软件是开源的。开源软件往往缺乏专门的支持结构，以及专有的软件包。虽然大企业有专门的开发人员，他们一般不会集中为这类软件提供支持。开源的web容器与web容器管理项目都基于稳定代码发布以及提供标准支持和配置，但很多还不成熟。随着时间推移，越来越多公司将在开源软件上有提供全面支持——类似OpenStack与Hadoop的进化过程。是每个人都可以通过web容器模型受益。但是web容器迟早会成为IT基础设施架构的一部分。正如任何新技术，初始部署web容器注定是坎坷的。大多数挑战会随着技术的发展迅速消散，但其余问题将有可能围绕这个技术一直存在。

 

 

Practice：

一、Git-Install and practice

1.版本控制工具

二、Maven-install and practice

 

 

 

 

 

 

 

 

三、Glassfish server installation and startup

当执行项目时mvn clean 和 mvn install 等报错误

可修改相应项目的顶层pom.xml  在里边的<glassfish.home.prefix> ？？？<glassfish.home.prefix> 和 <glassfish.home>？？？<glassfish.home> 中间添加你的glassfish目录

---

mvn 和glassfish命令行报不是内部命令错也有可能是maven配置路径出错

解决问题的方法是修改maven的setting.xml文件

---

 <!-- localRepository    | The path to the local repository maven will use to store artifacts.    |    | Default: ${user.home}/.m2/repository   <localRepository>E:MyEclipse 2017Mavenapache-maven-3.6.0/repository</localRepository>   -->

 <localRepository>E:MyEclipse 2017Mavenapache-maven-3.6.0/repository</localRepository>  <!-- interactiveMode

---

在你的maven下建一个文件夹repository

在<localRepository>？？？<localRepository>间输入你的文件夹repository的路径

并在<!-- interactiveMode前再复制张贴你的<localRepository>？？？<localRepository>一遍

就像我上边的一样

四、Java EE Tutarial Example-Hello1

下载组件配置环境：

---

• 下载javaee8，里边自带glassfish5
• 解压压缩包（glassfish不用安装不要问什么.exe）
• 下载Maven
• 解压Maven
• 配置Maven环境变量：
• MAVEN_HOME    你的maven路径
• path   %MAVEN_HOME%in

---

部署项目：

---

• 命令行 cd 到你的glassfish下的bin目录
• asadmin start-domain，开启glassfish服务器
• 命令行 cd 到你hello1的目录下
• mvn package 打包hello1生成一个war文件
• 打开网页输入localhost：8080
•  点击 go to the administration 那个，进入部署
• 点击左方application  在location 导入你hello1下的war文件
• 点 lanch 即可进入网页

---

hello2也一样打包部署，不过在打不开这hello2网页时，记住在网址后面加上/greeting就可以了。