首页 > 代码库 > 在linux中部署java项目
在linux中部署java项目
1、从svn中检出项目
svn co svn地址及项目目录（如：svn co http://172.18.59.101/svn/svnroot/project/testpro）
2、使用mvn下载项目依赖的包并打包项目（在pom.xml同级目录下输入命令）
mvn install ——在本地Repository中安装jar
mvn install:install-file -Dfile="lib/server-1.1.jar" -DgroupId="org.server" -DartifactId="server" -Dversion="1.1" -Dpackaging=jar ——发布第三方Jar到本地库中
mvn -e -X clean compile ——删除target目录下编译内容然后编译项目
mvn package ——打包
3、启动运行项目
附录：
一、mvn常用命令
1. 创建Maven的普通java项目：
mvn archetype:create -DgroupId=packageName -DartifactId=projectName
2. 创建Maven的Web项目：
mvn archetype:create -DgroupId=packageName -DartifactId=webappName -DarchetypeArtifactId=maven-archetype-webapp
3. 编译源代码： mvn compile
4. 编译测试代码：mvn test-compile
5. 运行测试：mvn test
6. 产生site（生成项目相关信息的网站）：mvn site
7. 打包（生成target目录，编译、测试代码，生成测试报告，生成jar/war文件）：mvn package
8. 在本地Repository中安装jar：mvn install
9. 清除产生的项目（删除target目录下编译内容）：mvn clean
10. 生成eclipse项目：mvn eclipse:eclipse
11. 生成idea项目：mvn idea:idea
12. 组合使用goal命令，如只打包不测试：mvn -Dtest package
13. 编译测试的内容：mvn test-compile
14. 只打jar包: mvn jar:jar
15. 只测试而不编译，也不测试编译：mvn test -skipping compile -skipping test-compile
( -skipping 的灵活运用，当然也可以用于其他组合命令)
16. 清除eclipse的一些系统设置:mvn eclipse:clean
17. 显示版本信息：mvn -version/-v
18. 生成Wtp插件的Web项目：mvn -Dwtpversion=1.0 eclipse:eclipse
19. 清除Eclipse项目的配置信息(Web项目)：mvn -Dwtpversion=1.0 eclipse:clean
20. 发布第三方Jar到本地库中：mvn install:install-file -DgroupId=com -DartifactId=client -Dversion=0.1.0 -Dpackaging=jar -Dfile=d:\client-0.1.0.jar
21. 显示详细错误信息：mvn -e
22. 验证工程是否正确，所有需要的资源是否可用：mvn validate
23. 编译项目测试代码：mvn test-compile
24. 在集成测试可以运行的环境中处理和发布包：mvn integration-test
25. 运行任何检查，验证包是否有效且达到质量标准：mvn verify
26. 产生应用需要的任何额外的源代码，如xdoclet：mvn generate-sources
27. Exec 插件让我们能够在不往classpath 载入适当的依赖的情况下，运行这个程序：mvn exec:java -Dexec.mainClass=org.sonatype.mavenbook.weather.Main
28. 打印出已解决依赖的列表：mvn dependency:resolve
29. 打印整个依赖树：mvn dependency:tree
30. 想要查看完整的依赖踪迹，包含那些因为冲突或者其它原因而被拒绝引入的构件，打开 Maven 的调试标记运行：mvn install -X
31. 构建装配Maven Assembly插件是一个用来创建你应用程序特有分发包的插件：mvn install assembly:assembly
32. 使用Hibernate3 插件构造数据库：mvn hibernate3:hbm2ddl
33. 使用 help 插件的 describe 目标来输出 Maven Help 插件的信息：mvn help:describe -Dplugin=help
34. 使用Help 插件输出完整的带有参数的目标列：mvn help:describe -Dplugin=help -Dfull
35. 获取单个目标的信息,设置 mojo 参数和 plugin 参数。此命令列出了Compiler 插件的compile 目标的所有信息：mvn help:describe -Dplugin=compiler -Dmojo=compile -Dfull
36. 列出所有 Maven Exec 插件可用的目标：mvn help:describe -Dplugin=exec -Dfull
37. 看这个“有效的 (effective)”POM，它暴露了 Maven的默认设置：mvn help:effective-pom
ps：
一般使用情况是这样，首先通过cvs或svn下载代码到本机，然后执行mvn eclipse:eclipse生成ecllipse项目文件，然后导入到eclipse就行了；修改代码后执行mvn compile或mvn test检验，也可以下载eclipse的maven插件。
在应用程序用使用多个存储库
<repositories>
<repository>
<id>Ibiblio</id>
<name>Ibiblio</name>
<url>http://www.ibiblio.org/maven/</url>
</repository>
<repository>
<id>PlanetMirror</id>
<name>Planet Mirror</name>
<url>http://public.planetmirror.com/pub/maven/</url>
</repository>
</repositories>
mvn deploy:deploy-file -DgroupId=com -DartifactId=client -Dversion=0.1.0 -Dpackaging=jar -Dfile=d:\client-0.1.0.jar -DrepositoryId=maven-repository-inner -Durl=ftp://xxxxxxx/opt/maven/repository/
二、svn冲突解决
第一种，利用update的选项进行冲突解决，也就是说不管当前拷贝副本是否是最新版本，都使用—accept参数作为冲突处理方式
–accept ARG : specify automatic conflict resolution action
(‘postpone’, ‘base’, ‘mine-conflict’,‘theirs-conflict’, ‘mine-full’, ‘theirs-full’,‘edit’, ‘launch’)
(p) postpone – mark the conflict to be resolved later //让文件在更新完成之后保持冲突状态。
(df) diff-full – show all changes made to merged file //使用标准区别格式显示base修订版本和冲突文件本身的区别。
(e) edit – change merged file in an editor //用你喜欢的编辑器打开冲突的文件，编辑器是环境变量EDITOR设置的。
(r) resolved – accept merged version of file //完成文件编辑之后，通知svn你已经解决了文件的冲突，它必须接受当前的内容—从本质上讲就是你已经“解决了”冲突。
(mf) mine-full – accept my version of entire file (ignore their change//丢弃新从服务器接收的变更，并只使用你查看文件的本地修改。
(tf) theirs-full – accept their version of entire file (lose my changes)//丢弃你对查看文件的本地修改，只使用从服务器新接收的变更。
(l) launch – launch external tool to resolve conflict//启动一个外置程序来执行冲突解决，这需要一些预先的准备。
(h) help – show this list //显示所有在冲突解决时可能使用的命令。
第二种，在update时并不处理冲突，利用svn resolve解决冲突
1、利用svn resolve –accept base选择base版本，即1.txt.rOld作为最后提交的版本
–accept ARG : specify automatic conflict resolution source
(‘base’, ‘working’, ‘mine-conflict’,‘theirs-conflict’, ‘mine-full’, ‘theirs-full’)
2、手工修改1.txt文件，然后将当前拷贝即1.txt作为最后提交的版本
svn resolve –accept working 1.txt
3、svn resolve –accept theirs-full 1.txt 使用1.txt.rNew作为最后提交的版本
4、svn resolve –accept mine-full 1.txt 使用1.txt.mine作为最后提交的版本
5、svn resolve –accept mine-conflict 1.txt 使用1.txt.mine的冲突部分作为最后提交的版本
6、svn resolve –accept theirs-conflict 1.txt 使用1.txt.rNew的冲突部分作为最后提交的版本
第三种，使用svn revert取消变更
前两天在解决冲突时用到了svn resolve这个命令，找到这篇文章主要是因为他对–accept参数的说明比较全比官方的文档更详细。
冲突分类
偶尔，当你从版本库更新、合并文件时，或者切换工作副本至一个不同的 URL 时你会遇到冲突。有两种冲突:
- 文件冲突
当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。
- 树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。
文件冲突
当两名或更多开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。由于 Subversion 不知道你的项目的具体情况，它把解决冲突的工作留给了开发人员。一旦出现冲突，你就应该打开有问题的文件，查找以字符串<<<<<<<开头的行。有冲突的区域用如下的方式标记:
<<<<<<< 文件名 你的修改 ======= 合并自版本库中的代码 >>>>>>> 版本
对于每个冲突的文件 Subversion 在你的目录下放置了三个文件:
- 文件名.ext.mine
这是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。
- 文件名.ext.r旧版本
这是在你更新你的工作副本之前的基础版本(BASE revision)文件。也就是说，它是在你做最后修改之前所检出的文件。
- 文件名.ext.r新版本
这个文件是当你更新你的工作副本时，你的 Subversion 客户端从服务器接收到的。这个文件对应于版本库中的最新版本。
你可以通过TortoiseSVN → 编辑冲突运行外部合并工具/冲突编辑器，或者你可以使用任何别的编辑器手动解决冲突。你需要冲定哪些代码是需要的，做一些必要的修改然后保存。
然后，执行命令TortoiseSVN → 已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了filename.ext.mine和filename.ext.r*两个文件，允许你提交修改。
如果你的二进制文件有冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到filename.ext.r*文件。如果你要撤消你的修改，保留版本库中的版本，请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本，使用已解决命令，然后提交你的版本。
你可以右击父文件夹，选择TortoiseSVN → 已解决...，使用“已解决”命令来解决多个文件。这个操作会出现一个对话框，列出文件夹下所有有冲突的文件，你可以选择将哪些标记成已解决。
树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突，而且不同的情形需要不同的步骤来解决冲突。
当一个文件通过 Subversion 在本机删除后，文件也从本机文件系统中删除。因此即使它是树冲突的一部分，却既不能显示冲突的叠加图标也不能通过右键单击来解决冲突。使用检查修改对话框来获得编辑冲突选项。
TortoiseSVN 能够协助找到合并更改的正确位置，但是需要作一些额外的工作来整理冲突。请牢记: 当进行一次更新操作后，工作副本的基础文件将会包括每一个项目在执行更新操作时版本库中的版本。如果你在进行更新后再撤销更改，工作副本将返回到版本库的 状态，而不是你开始进行更改前的状态。
本地删除，当更新时有更改进入
开发人员 A 修改 Foo.c 并将其提交至版本库中
开发人员 B 同时在他的工作副本中将文件 Foo.c 改名为 Bar.c，或者仅仅是删除了 Foo.c 或它的父文件夹。
更新开发人员 B 的工作副本会导致树冲突:
在工作副本中，Foo.c 被删除了，但是被标记为树冲突。
如果冲突是由于更改文件名引起的而不是删除文件引起的，那么 Bar.c 被标记为添加，但是其中却不包括开发人员 A 修改的内容。
开发人员 B 现在必须做出选择是否保留开发人员 A 的更改。在更改文件名的案例中，他可以将 Foo.c 的更改合并到改名后的文件 Bar.c 中去。对于删除文件或文件夹的案例中，他可以选择保留包含开发人员 A 更改内容的项目并放弃删除操作。或什么也不做而直接将冲突标记为已解决，那样他实际上丢弃了开发人员 A 的更改。
如果 TortoiseSVN 能够找到被改名为 Bar.c 的原始文件，冲突编辑对话框将可以合并更改。这取决于在什么地方调用更新操作，它也许不能找到原始文件。
本地更改，当更新时有删除进入
开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。
开发人员 B 在他的工作副本中修改文件 Foo.c。
或者在一个文件夹改名的案例中...
开发人员 A 将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。
开发人员 B 在他的工作副本中修改文件 Foo.c。
更新开发人员 B 的工作副本会导致树冲突。对于一个简单的文件冲突:
Bar.c 被当作一个正常文件添加到工作副本中。
Foo.c 被标记为添加(包括其历史记录)并且产生树冲突。
对于一个文件夹冲突:
BarFolder 被当作一个正常文件夹添加到工作副本中。
FooFolder 被标记为添加(包括其历史记录)并且产生树冲突。
Foo.c 被标记为已修改。
开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。
如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。
本地删除，当更新时有删除进入
开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。
开发人员 B 将文件 Foo.c 改名为 Bix.c
更新开发人员 B 的工作副本会导致树冲突:
Bix.c 被标记为添加(包括其历史记录)。
Bar.c 被添加到工作副本中，其状态为‘正常’。
Foo.c 被标记为删除并且产生一个树冲突。
要解决这个冲突，开发人员 B 必须找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。
然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。
在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。
本地缺少，当合并时有更改进入
开发人员 A 在主干上工作，修改 Foo.c 并将其提交至版本库中
开发人员 B 在分支上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中
合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:
Bar.c 已经存在于工作副本中，其状态为‘正常’。
Foo.c 被标记为缺少并产生树冲突。
要解决这个冲突，开发人员 B 要在冲突编辑对话框中标记文件为已解决，这样就会将其从冲突列表中删除。她接下来需要决定是否将缺少的文件 Foo.c 从版本库中复制到工作副本中，是否将开发人员 A 的对 Foo.c 的更改和合并到改名后的 Bar.c 或者是否通过标记冲突为已解决来忽略更改什么事也不做。
注意，如果你将缺少的文件从版本库中复制到工作副本中然后再标记为已解决，你复制下来的文件将被再次删除。你必须先解决冲突。
本地更改，当合并时有删除进入
开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中
开发人员 B 在分支上工作，修改 Foo.c 并将其提交至版本库中
当文件夹改名时有类似的案例，但是在 Subversion 1.6 中还未被识别...
开发人员 A 在主干上工作，将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。
开发人员 B 在分支上工作，在她的工作副本中修改 Foo.c 。
合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:
Bar.c 被标记为添加。
Foo.c 被标记为修改并产生树冲突。
开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路 径的更改合并进来，所以你需要自己找到它。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可 以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。
如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。
本地删除，当合并时有删除进入
开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中
开发人员 B 工作在分之上，将 Foo.c 改名为 Bix.c 并将其提交至版本库中
合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:
Bix.c 被标记为正常(未修改)状态。
Bar.c 被标记为添加(包括其历史记录)。
Foo.c 被标记为缺少并且产生树冲突。
要解决这个冲突，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。
然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。
在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。
关于我的解决方法
本人遇到这个问题,不管怎么样都无法删除。最后只得删除本地的所有文件，重新更新库。然后再删除想要删除的文件，最后提交。不在出现这个问题了。
来自: http://hi.baidu.com/ostech/blog/item/1c6ea627ca67af6b34a80f91.html
本文来自转载请标明出处：http://blog.csdn.net/lifxue/archive/2009/10/14/4662902.aspx
在linux中部署java项目