`
yaerfeng1989
  • 浏览: 234127 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

史上最全的maven pom.xml文件教程详解

阅读更多

原创整理不易,转载请注明出处:史上最全的maven pom.xml文件教程详解

代码下载地址:http://www.zuidaima.com/share/1781583829978112.htm

<project xmlns="http://maven.apache.org/POM/4.0.0" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd "> 

<!-- 父项目的坐标。如果项目中没有规定某个元素的值,那么父项目中的对应值即为项目的默认值。 坐标包括group ID,artifact ID和 version。 --> 

<parent> 

<!-- 被继承的父项目的构件标识符 --> 

<artifactId /> 

<!-- 被继承的父项目的全球唯一标识符 --> 

<groupId /> 

<!-- 被继承的父项目的版本 --> 

<version /> 

<!-- 父项目的pom.xml文件的相对路径。相对路径允许你选择一个不同的路径。默认值是../pom.xml。Maven首先在构建当前项目的地方寻找父项目的pom,其次在文件系统的这个位置(relativePath位置),然后在本地仓库,最后在远程仓库寻找父项目的pom。 --> 

<relativePath /> 

</parent> 

<!-- 声明项目描述符遵循哪一个POM模型版本。模型本身的版本很少改变,虽然如此,但它仍然是必不可少的,这是为了当Maven引入了新的特性或者其他模型变更的时候,确保稳定性。 --> 

<modelVersion> 4.0.0 </modelVersion> 

<!-- 项目的全球唯一标识符,通常使用全限定的包名区分该项目和其他项目。并且构建时生成的路径也是由此生成, 如com.mycompany.app生成的相对路径为:/com/mycompany/app --> 

<groupId> asia.banseon </groupId> 

<!-- 构件的标识符,它和group ID一起唯一标识一个构件。换句话说,你不能有两个不同的项目拥有同样的artifact ID和groupID;在某个特定的group ID下,artifact ID也必须是唯一的。构件是项目产生的或使用的一个东西,Maven为项目产生的构件包括:JARs,源码,二进制发布和WARs等。 --> 

<artifactId> banseon-maven2 </artifactId> 

<!-- 项目产生的构件类型,例如jar、war、ear、pom。插件可以创建他们自己的构件类型,所以前面列的不是全部构件类型 --> 

<packaging> jar </packaging> 

<!-- 项目当前版本,格式为:主版本.次版本.增量版本-限定版本号 --> 

<version> 1.0-SNAPSHOT </version> 

<!-- 项目的名称, Maven产生的文档用 --> 

<name> banseon-maven </name> 

<!-- 项目主页的URL, Maven产生的文档用 --> 

<url> http://www.baidu.com/banseon </url> 

<!-- 项目的详细描述, Maven 产生的文档用。 当这个元素能够用HTML格式描述时(例如,CDATA中的文本会被解析器忽略,就可以包含HTML标签), 不鼓励使用纯文本描述。如果你需要修改产生的web站点的索引页面,你应该修改你自己的索引页文件,而不是调整这里的文档。 --> 

<description> A maven project to study maven. </description> 

<!-- 描述了这个项目构建环境中的前提条件。 --> 

<prerequisites> 

<!-- 构建该项目或使用该插件所需要的Maven的最低版本 --> 

<maven /> 

</prerequisites> 

<!-- 项目的问题管理系统(Bugzilla, Jira, Scarab,或任何你喜欢的问题管理系统)的名称和URL,本例为 jira --> 

<issueManagement> 

<!-- 问题管理系统(例如jira)的名字, --> 

<system> jira </system> 

<!-- 该项目使用的问题管理系统的URL --> 

<url> http://jira.baidu.com/banseon </url> 

</issueManagement> 

<!-- 项目持续集成信息 --> 

<ciManagement> 

<!-- 持续集成系统的名字,例如continuum --> 

<system /> 

<!-- 该项目使用的持续集成系统的URL(如果持续集成系统有web接口的话)。 --> 

<url /> 

<!-- 构建完成时,需要通知的开发者/用户的配置项。包括被通知者信息和通知条件(错误,失败,成功,警告) --> 

<notifiers> 

<!-- 配置一种方式,当构建中断时,以该方式通知用户/开发者 --> 

<notifier> 

<!-- 传送通知的途径 --> 

<type /> 

<!-- 发生错误时是否通知 --> 

<sendOnError /> 

<!-- 构建失败时是否通知 --> 

<sendOnFailure /> 

<!-- 构建成功时是否通知 --> 

<sendOnSuccess /> 

<!-- 发生警告时是否通知 --> 

<sendOnWarning /> 

<!-- 不赞成使用。通知发送到哪里 --> 

<address /> 

<!-- 扩展配置项 --> 

<configuration /> 

</notifier> 

</notifiers> 

</ciManagement> 

<!-- 项目创建年份,4位数字。当产生版权信息时需要使用这个值。 --> 

<inceptionYear /> 

<!-- 项目相关邮件列表信息 --> 

<mailingLists> 

<!-- 该元素描述了项目相关的所有邮件列表。自动产生的网站引用这些信息。 --> 

<mailingList> 

<!-- 邮件的名称 --> 

<name> Demo </name> 

<!-- 发送邮件的地址或链接,如果是邮件地址,创建文档时,mailto: 链接会被自动创建 --> 

<post> banseon@126.com </post> 

<!-- 订阅邮件的地址或链接,如果是邮件地址,创建文档时,mailto: 链接会被自动创建 --> 

<subscribe> banseon@126.com </subscribe> 

<!-- 取消订阅邮件的地址或链接,如果是邮件地址,创建文档时,mailto: 链接会被自动创建 --> 

<unsubscribe> banseon@126.com </unsubscribe> 

<!-- 你可以浏览邮件信息的URL --> 

<archive> http:/hi.baidu.com/banseon/demo/dev/ </archive> 

</mailingList> 

</mailingLists> 

<!-- 项目开发者列表 --> 

<developers> 

<!-- 某个项目开发者的信息 --> 

<developer> 

<!-- SCM里项目开发者的唯一标识符 --> 

<id> HELLO WORLD </id> 

<!-- 项目开发者的全名 --> 

<name> banseon </name> 

<!-- 项目开发者的email --> 

<email> banseon@126.com </email> 

<!-- 项目开发者的主页的URL --> 

<url /> 

<!-- 项目开发者在项目中扮演的角色,角色元素描述了各种角色 --> 

<roles> 

<role> Project Manager </role> 

<role> Architect </role> 

</roles> 

<!-- 项目开发者所属组织 --> 

<organization> demo </organization> 

<!-- 项目开发者所属组织的URL --> 

<organizationUrl> http://hi.baidu.com/banseon </organizationUrl> 

<!-- 项目开发者属性,如即时消息如何处理等 --> 

<properties> 

<dept> No </dept> 

</properties> 

<!-- 项目开发者所在时区, -11到12范围内的整数。 --> 

<timezone> -5 </timezone> 

</developer> 

</developers> 

<!-- 项目的其他贡献者列表 --> 

<contributors> 

<!-- 项目的其他贡献者。参见developers/developer元素 --> 

<contributor> 

<name /><email /><url /><organization /><organizationUrl /><roles /><timezone /><properties /> 

</contributor> 

</contributors> 

<!-- 该元素描述了项目所有License列表。 应该只列出该项目的license列表,不要列出依赖项目的 license列表。如果列出多个license,用户可以选择它们中的一个而不是接受所有license。 --> 

<licenses> 

<!-- 描述了项目的license,用于生成项目的web站点的license页面,其他一些报表和validation也会用到该元素。 --> 

<license> 

<!-- license用于法律上的名称 --> 

<name> Apache 2 </name> 

<!-- 官方的license正文页面的URL --> 

<url> http://www.baidu.com/banseon/LICENSE-2.0.txt </url> 

<!-- 项目分发的主要方式: 

repo,可以从Maven库下载 

manual, 用户必须手动下载和安装依赖 --> 

<distribution> repo </distribution> 

<!-- 关于license的补充信息 --> 

<comments> A business-friendly OSS license </comments> 

</license> 

</licenses> 

<!-- SCM(Source Control Management)标签允许你配置你的代码库,供Maven web站点和其它插件使用。 --> 

<scm> 

<!-- SCM的URL,该URL描述了版本库和如何连接到版本库。欲知详情,请看SCMs提供的URL格式和列表。该连接只读。 --> 

<connection> 

scm:svn:http://svn.baidu.com/banseon/maven/banseon/banseon-maven2-trunk(dao-trunk) 

</connection> 

<!-- 给开发者使用的,类似connection元素。即该连接不仅仅只读 --> 

<developerConnection> 

scm:svn:http://svn.baidu.com/banseon/maven/banseon/dao-trunk 

</developerConnection> 

<!-- 当前代码的标签,在开发阶段默认为HEAD --> 

<tag /> 

<!-- 指向项目的可浏览SCM库(例如ViewVC或者Fisheye)的URL。 --> 

<url> http://svn.baidu.com/banseon </url> 

</scm> 

<!-- 描述项目所属组织的各种属性。Maven产生的文档用 --> 

<organization> 

<!-- 组织的全名 --> 

<name> demo </name> 

<!-- 组织主页的URL --> 

<url> http://www.baidu.com/banseon </url> 

</organization> 

<!-- 构建项目需要的信息 --> 

<build> 

<!-- 该元素设置了项目源码目录,当构建项目的时候,构建系统会编译目录里的源码。该路径是相对于pom.xml的相对路径。 --> 

<sourceDirectory /> 

<!-- 该元素设置了项目脚本源码目录,该目录和源码目录不同:绝大多数情况下,该目录下的内容 会被拷贝到输出目录(因为脚本是被解释的,而不是被编译的)。 --> 

<scriptSourceDirectory /> 

<!-- 该元素设置了项目单元测试使用的源码目录,当测试项目的时候,构建系统会编译目录里的源码。该路径是相对于pom.xml的相对路径。 --> 

<testSourceDirectory /> 

<!-- 被编译过的应用程序class文件存放的目录。 --> 

<outputDirectory /> 

<!-- 被编译过的测试class文件存放的目录。 --> 

<testOutputDirectory /> 

<!-- 使用来自该项目的一系列构建扩展 --> 

<extensions> 

<!-- 描述使用到的构建扩展。 --> 

<extension> 

<!-- 构建扩展的groupId --> 

<groupId /> 

<!-- 构建扩展的artifactId --> 

<artifactId /> 

<!-- 构建扩展的版本 --> 

<version /> 

</extension> 

</extensions> 

<!-- 当项目没有规定目标(Maven2 叫做阶段)时的默认值 --> 

<defaultGoal /> 

<!-- 这个元素描述了项目相关的所有资源路径列表,例如和项目相关的属性文件,这些资源被包含在最终的打包文件里。 --> 

<resources> 

<!-- 这个元素描述了项目相关或测试相关的所有资源路径 --> 

<resource> 

<!-- 描述了资源的目标路径。该路径相对target/classes目录(例如${project.build.outputDirectory})。举个例子,如果你想资源在特定的包里(org.apache.maven.messages),你就必须该元素设置为org/apache/maven/messages。然而,如果你只是想把资源放到源码目录结构里,就不需要该配置。 --> 

<targetPath /> 

<!-- 是否使用参数值代替参数名。参数值取自properties元素或者文件里配置的属性,文件在filters元素里列出。 --> 

<filtering /> 

<!-- 描述存放资源的目录,该路径相对POM路径 --> 

<directory /> 

<!-- 包含的模式列表,例如**/*.xml. --> 

<includes /> 

<!-- 排除的模式列表,例如**/*.xml --> 

<excludes /> 

</resource> 

</resources> 

<!-- 这个元素描述了单元测试相关的所有资源路径,例如和单元测试相关的属性文件。 --> 

<testResources> 

<!-- 这个元素描述了测试相关的所有资源路径,参见build/resources/resource元素的说明 --> 

<testResource> 

<targetPath /><filtering /><directory /><includes /><excludes /> 

</testResource> 

</testResources> 

<!-- 构建产生的所有文件存放的目录 --> 

<directory /> 

<!-- 产生的构件的文件名,默认值是${artifactId}-${version}。 --> 

<finalName /> 

<!-- 当filtering开关打开时,使用到的过滤器属性文件列表 --> 

<filters /> 

<!-- 子项目可以引用的默认插件信息。该插件配置项直到被引用时才会被解析或绑定到生命周期。给定插件的任何本地配置都会覆盖这里的配置 --> 

<pluginManagement> 

<!-- 使用的插件列表 。 --> 

<plugins> 

<!-- plugin元素包含描述插件所需要的信息。 --> 

<plugin> 

<!-- 插件在仓库里的group ID --> 

<groupId /> 

<!-- 插件在仓库里的artifact ID --> 

<artifactId /> 

<!-- 被使用的插件的版本(或版本范围) --> 

<version /> 

<!-- 是否从该插件下载Maven扩展(例如打包和类型处理器),由于性能原因,只有在真需要下载时,该元素才被设置成enabled。 --> 

<extensions /> 

<!-- 在构建生命周期中执行一组目标的配置。每个目标可能有不同的配置。 --> 

<executions> 

<!-- execution元素包含了插件执行需要的信息 --> 

<execution> 

<!-- 执行目标的标识符,用于标识构建过程中的目标,或者匹配继承过程中需要合并的执行目标 --> 

<id /> 

<!-- 绑定了目标的构建生命周期阶段,如果省略,目标会被绑定到源数据里配置的默认阶段 --> 

<phase /> 

<!-- 配置的执行目标 --> 

<goals /> 

<!-- 配置是否被传播到子POM --> 

<inherited /> 

<!-- 作为DOM对象的配置 --> 

<configuration /> 

</execution> 

</executions> 

<!-- 项目引入插件所需要的额外依赖 --> 

<dependencies> 

<!-- 参见dependencies/dependency元素 --> 

<dependency> 



</dependency> 

</dependencies> 

<!-- 任何配置是否被传播到子项目 --> 

<inherited /> 

<!-- 作为DOM对象的配置 --> 

<configuration /> 

</plugin> 

</plugins> 

</pluginManagement> 

<!-- 使用的插件列表 --> 

<plugins> 

<!-- 参见build/pluginManagement/plugins/plugin元素 --> 

<plugin> 

<groupId /><artifactId /><version /><extensions /> 

<executions> 

<execution> 

<id /><phase /><goals /><inherited /><configuration /> 

</execution> 

</executions> 

<dependencies> 

<!-- 参见dependencies/dependency元素 --> 

<dependency> 



</dependency> 

</dependencies> 

<goals /><inherited /><configuration /> 

</plugin> 

</plugins> 

</build> 

<!-- 在列的项目构建profile,如果被激活,会修改构建处理 --> 

<profiles> 

<!-- 根据环境参数或命令行参数激活某个构建处理 --> 

<profile> 

<!-- 构建配置的唯一标识符。即用于命令行激活,也用于在继承时合并具有相同标识符的profile。 --> 

<id /> 

<!-- 自动触发profile的条件逻辑。Activation是profile的开启钥匙。profile的力量来自于它 

能够在某些特定的环境中自动使用某些特定的值;这些环境通过activation元素指定。activation元素并不是激活profile的唯一方式。 --> 

<activation> 

<!-- profile默认是否激活的标志 --> 

<activeByDefault /> 

<!-- 当匹配的jdk被检测到,profile被激活。例如,1.4激活JDK1.4,1.4.0_2,而!1.4激活所有版本不是以1.4开头的JDK。 --> 

<jdk /> 

<!-- 当匹配的操作系统属性被检测到,profile被激活。os元素可以定义一些操作系统相关的属性。 --> 

<os> 

<!-- 激活profile的操作系统的名字 --> 

<name> Windows XP </name> 

<!-- 激活profile的操作系统所属家族(如 'windows') --> 

<family> Windows </family> 

<!-- 激活profile的操作系统体系结构 --> 

<arch> x86 </arch> 

<!-- 激活profile的操作系统版本 --> 

<version> 5.1.2600 </version> 

</os> 

<!-- 如果Maven检测到某一个属性(其值可以在POM中通过${名称}引用),其拥有对应的名称和值,Profile就会被激活。如果值 

字段是空的,那么存在属性名称字段就会激活profile,否则按区分大小写方式匹配属性值字段 --> 

<property> 

<!-- 激活profile的属性的名称 --> 

<name> mavenVersion </name> 

<!-- 激活profile的属性的值 --> 

<value> 2.0.3 </value> 

</property> 

<!-- 提供一个文件名,通过检测该文件的存在或不存在来激活profile。missing检查文件是否存在,如果不存在则激活 

profile。另一方面,exists则会检查文件是否存在,如果存在则激活profile。 --> 

<file> 

<!-- 如果指定的文件存在,则激活profile。 --> 

<exists> /usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/ </exists> 

<!-- 如果指定的文件不存在,则激活profile。 --> 

<missing> /usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/ </missing> 

</file> 

</activation> 

<!-- 构建项目所需要的信息。参见build元素 --> 

<build> 

<defaultGoal /> 

<resources> 

<resource> 

<targetPath /><filtering /><directory /><includes /><excludes /> 

</resource> 

</resources> 

<testResources> 

<testResource> 

<targetPath /><filtering /><directory /><includes /><excludes /> 

</testResource> 

</testResources> 

<directory /><finalName /><filters /> 

<pluginManagement> 

<plugins> 

<!-- 参见build/pluginManagement/plugins/plugin元素 --> 

<plugin> 

<groupId /><artifactId /><version /><extensions /> 

<executions> 

<execution> 

<id /><phase /><goals /><inherited /><configuration /> 

</execution> 

</executions> 

<dependencies> 

<!-- 参见dependencies/dependency元素 --> 

<dependency> 



</dependency> 

</dependencies> 

<goals /><inherited /><configuration /> 

</plugin> 

</plugins> 

</pluginManagement> 

<plugins> 

<!-- 参见build/pluginManagement/plugins/plugin元素 --> 

<plugin> 

<groupId /><artifactId /><version /><extensions /> 

<executions> 

<execution> 

<id /><phase /><goals /><inherited /><configuration /> 

</execution> 

</executions> 

<dependencies> 

<!-- 参见dependencies/dependency元素 --> 

<dependency> 



</dependency> 

</dependencies> 

<goals /><inherited /><configuration /> 

</plugin> 

</plugins> 

</build> 

<!-- 模块(有时称作子项目) 被构建成项目的一部分。列出的每个模块元素是指向该模块的目录的相对路径 --> 

<modules /> 

<!-- 发现依赖和扩展的远程仓库列表。 --> 

<repositories> 

<!-- 参见repositories/repository元素 --> 

<repository> 

<releases> 

<enabled /><updatePolicy /><checksumPolicy /> 

</releases> 

<snapshots> 

<enabled /><updatePolicy /><checksumPolicy /> 

</snapshots> 

<id /><name /><url /><layout /> 

</repository> 

</repositories> 

<!-- 发现插件的远程仓库列表,这些插件用于构建和报表 --> 

<pluginRepositories> 

<!-- 包含需要连接到远程插件仓库的信息.参见repositories/repository元素 --> 

<pluginRepository> 

<releases> 

<enabled /><updatePolicy /><checksumPolicy /> 

</releases> 

<snapshots> 

<enabled /><updatePolicy /><checksumPolicy /> 

</snapshots> 

<id /><name /><url /><layout /> 

</pluginRepository> 

</pluginRepositories> 

<!-- 该元素描述了项目相关的所有依赖。 这些依赖组成了项目构建过程中的一个个环节。它们自动从项目定义的仓库中下载。要获取更多信息,请看项目依赖机制。 --> 

<dependencies> 

<!-- 参见dependencies/dependency元素 --> 

<dependency> 



</dependency> 

</dependencies> 

<!-- 不赞成使用. 现在Maven忽略该元素. --> 

<reports /> 

<!-- 该元素包括使用报表插件产生报表的规范。当用户执行“mvn site”,这些报表就会运行。 在页面导航栏能看到所有报表的链接。参见reporting元素 --> 

<reporting> 



</reporting> 

<!-- 参见dependencyManagement元素 --> 

<dependencyManagement> 

<dependencies> 

<!-- 参见dependencies/dependency元素 --> 

<dependency> 



</dependency> 

</dependencies> 

</dependencyManagement> 

<!-- 参见distributionManagement元素 --> 

<distributionManagement> 



</distributionManagement> 

<!-- 参见properties元素 --> 

<properties /> 

</profile> 

</profiles> 

<!-- 模块(有时称作子项目) 被构建成项目的一部分。列出的每个模块元素是指向该模块的目录的相对路径 --> 

<modules /> 

<!-- 发现依赖和扩展的远程仓库列表。 --> 

<repositories> 

<!-- 包含需要连接到远程仓库的信息 --> 

<repository> 

<!-- 如何处理远程仓库里发布版本的下载 --> 

<releases> 

<!-- true或者false表示该仓库是否为下载某种类型构件(发布版,快照版)开启。 --> 

<enabled /> 

<!-- 该元素指定更新发生的频率。Maven会比较本地POM和远程POM的时间戳。这里的选项是:always(一直),daily(默认,每日),interval:X(这里X是以分钟为单位的时间间隔),或者never(从不)。 --> 

<updatePolicy /> 

<!-- 当Maven验证构件校验文件失败时该怎么做:ignore(忽略),fail(失败),或者warn(警告)。 --> 

<checksumPolicy /> 

</releases> 

<!-- 如何处理远程仓库里快照版本的下载。有了releases和snapshots这两组配置,POM就可以在每个单独的仓库中,为每种类型的构件采取不同的策略。例如,可能有人会决定只为开发目的开启对快照版本下载的支持。参见repositories/repository/releases元素 --> 

<snapshots> 

<enabled /><updatePolicy /><checksumPolicy /> 

</snapshots> 

<!-- 远程仓库唯一标识符。可以用来匹配在settings.xml文件里配置的远程仓库 --> 

<id> banseon-repository-proxy </id> 

<!-- 远程仓库名称 --> 

<name> banseon-repository-proxy </name> 

<!-- 远程仓库URL,按protocol://hostname/path形式 --> 

<url> http://192.168.1.169:9999/repository/ </url> 

<!-- 用于定位和排序构件的仓库布局类型-可以是default(默认)或者legacy(遗留)。Maven 2为其仓库提供了一个默认的布局;然而,Maven 1.x有一种不同的布局。我们可以使用该元素指定布局是default(默认)还是legacy(遗留)。 --> 

<layout> default </layout> 

</repository> 

</repositories> 

<!-- 发现插件的远程仓库列表,这些插件用于构建和报表 --> 

<pluginRepositories> 

<!-- 包含需要连接到远程插件仓库的信息.参见repositories/repository元素 --> 

<pluginRepository> 



</pluginRepository> 

</pluginRepositories> 



<!-- 该元素描述了项目相关的所有依赖。 这些依赖组成了项目构建过程中的一个个环节。它们自动从项目定义的仓库中下载。要获取更多信息,请看项目依赖机制。 --> 

<dependencies> 

<dependency> 

<!-- 依赖的group ID --> 

<groupId> org.apache.maven </groupId> 

<!-- 依赖的artifact ID --> 

<artifactId> maven-artifact </artifactId> 

<!-- 依赖的版本号。 在Maven 2里, 也可以配置成版本号的范围。 --> 

<version> 3.8.1 </version> 

<!-- 依赖类型,默认类型是jar。它通常表示依赖的文件的扩展名,但也有例外。一个类型可以被映射成另外一个扩展名或分类器。类型经常和使用的打包方式对应,尽管这也有例外。一些类型的例子:jar,war,ejb-client和test-jar。如果设置extensions为 true,就可以在plugin里定义新的类型。所以前面的类型的例子不完整。 --> 

<type> jar </type> 

<!-- 依赖的分类器。分类器可以区分属于同一个POM,但不同构建方式的构件。分类器名被附加到文件名的版本号后面。例如,如果你想要构建两个单独的构件成JAR,一个使用Java 1.4编译器,另一个使用Java 6编译器,你就可以使用分类器来生成两个单独的JAR构件。 --> 

<classifier></classifier> 

<!-- 依赖范围。在项目发布过程中,帮助决定哪些构件被包括进来。欲知详情请参考依赖机制。 

- compile :默认范围,用于编译 

- provided:类似于编译,但支持你期待jdk或者容器提供,类似于classpath 

- runtime: 在执行时需要使用 

- test: 用于test任务时使用 

- system: 需要外在提供相应的元素。通过systemPath来取得 

- systemPath: 仅用于范围为system。提供相应的路径 

- optional: 当项目自身被依赖时,标注依赖是否传递。用于连续依赖时使用 --> 

<scope> test </scope> 

<!-- 仅供system范围使用。注意,不鼓励使用这个元素,并且在新的版本中该元素可能被覆盖掉。该元素为依赖规定了文件系统上的路径。需要绝对路径而不是相对路径。推荐使用属性匹配绝对路径,例如${java.home}。 --> 

<systemPath></systemPath> 

<!-- 当计算传递依赖时, 从依赖构件列表里,列出被排除的依赖构件集。即告诉maven你只依赖指定的项目,不依赖项目的依赖。此元素主要用于解决版本冲突问题 --> 

<exclusions> 

<exclusion> 

<artifactId> spring-core </artifactId> 

<groupId> org.springframework </groupId> 

</exclusion> 

</exclusions> 

<!-- 可选依赖,如果你在项目B中把C依赖声明为可选,你就需要在依赖于B的项目(例如项目A)中显式的引用对C的依赖。可选依赖阻断依赖的传递性。 --> 

<optional> true </optional> 

</dependency> 

</dependencies> 

<!-- 不赞成使用. 现在Maven忽略该元素. --> 

<reports></reports> 

<!-- 该元素描述使用报表插件产生报表的规范。当用户执行“mvn site”,这些报表就会运行。 在页面导航栏能看到所有报表的链接。 --> 

<reporting> 

<!-- true,则,网站不包括默认的报表。这包括“项目信息”菜单中的报表。 --> 

<excludeDefaults /> 

<!-- 所有产生的报表存放到哪里。默认值是${project.build.directory}/site。 --> 

<outputDirectory /> 

<!-- 使用的报表插件和他们的配置。 --> 

<plugins> 

<!-- plugin元素包含描述报表插件需要的信息 --> 

<plugin> 

<!-- 报表插件在仓库里的group ID --> 

<groupId /> 

<!-- 报表插件在仓库里的artifact ID --> 

<artifactId /> 

<!-- 被使用的报表插件的版本(或版本范围) --> 

<version /> 

<!-- 任何配置是否被传播到子项目 --> 

<inherited /> 

<!-- 报表插件的配置 --> 

<configuration /> 

<!-- 一组报表的多重规范,每个规范可能有不同的配置。一个规范(报表集)对应一个执行目标 。例如,有1,2,3,4,5,6,7,8,9个报表。1,2,5构成A报表集,对应一个执行目标。2,5,8构成B报表集,对应另一个执行目标 --> 

<reportSets> 

<!-- 表示报表的一个集合,以及产生该集合的配置 --> 

<reportSet> 

<!-- 报表集合的唯一标识符,POM继承时用到 --> 

<id /> 

<!-- 产生报表集合时,被使用的报表的配置 --> 

<configuration /> 

<!-- 配置是否被继承到子POMs --> 

<inherited /> 

<!-- 这个集合里使用到哪些报表 --> 

<reports /> 

</reportSet> 

</reportSets> 

</plugin> 

</plugins> 

</reporting> 

<!-- 继承自该项目的所有子项目的默认依赖信息。这部分的依赖信息不会被立即解析,而是当子项目声明一个依赖(必须描述group ID和artifact ID信息),如果group ID和artifact ID以外的一些信息没有描述,则通过group ID和artifact ID匹配到这里的依赖,并使用这里的依赖信息。 --> 

<dependencyManagement> 

<dependencies> 

<!-- 参见dependencies/dependency元素 --> 

<dependency> 



</dependency> 

</dependencies> 

</dependencyManagement> 

<!-- 项目分发信息,在执行mvn deploy后表示要发布的位置。有了这些信息就可以把网站部署到远程服务器或者把构件部署到远程仓库。 --> 

<distributionManagement> 

<!-- 部署项目产生的构件到远程仓库需要的信息 --> 

<repository> 

<!-- 是分配给快照一个唯一的版本号(由时间戳和构建流水号)?还是每次都使用相同的版本号?参见repositories/repository元素 --> 

<uniqueVersion /> 

<id> banseon-maven2 </id> 

<name> banseon maven2 </name> 

<url> file://${basedir}/target/deploy </url> 

<layout /> 

</repository> 

<!-- 构件的快照部署到哪里?如果没有配置该元素,默认部署到repository元素配置的仓库,参见distributionManagement/repository元素 --> 

<snapshotRepository> 

<uniqueVersion /> 

<id> banseon-maven2 </id> 

<name> Banseon-maven2 Snapshot Repository </name> 

<url> scp://svn.baidu.com/banseon:/usr/local/maven-snapshot </url> 

<layout /> 

</snapshotRepository> 

<!-- 部署项目的网站需要的信息 --> 

<site> 

<!-- 部署位置的唯一标识符,用来匹配站点和settings.xml文件里的配置 --> 

<id> banseon-site </id> 

<!-- 部署位置的名称 --> 

<name> business api website </name> 

<!-- 部署位置的URL,按protocol://hostname/path形式 --> 

<url> 

scp://svn.baidu.com/banseon:/var/www/localhost/banseon-web 

</url> 

</site> 

<!-- 项目下载页面的URL。如果没有该元素,用户应该参考主页。使用该元素的原因是:帮助定位那些不在仓库里的构件(由于license限制)。 --> 

<downloadUrl /> 

<!-- 如果构件有了新的group ID和artifact ID(构件移到了新的位置),这里列出构件的重定位信息。 --> 

<relocation> 

<!-- 构件新的group ID --> 

<groupId /> 

<!-- 构件新的artifact ID --> 

<artifactId /> 

<!-- 构件新的版本号 --> 

<version /> 

<!-- 显示给用户的,关于移动的额外信息,例如原因。 --> 

<message /> 

</relocation> 

<!-- 给出该构件在远程仓库的状态。不得在本地项目中设置该元素,因为这是工具自动更新的。有效的值有:none(默认),converted(仓库管理员从Maven 1 POM转换过来),partner(直接从伙伴Maven 2仓库同步过来),deployed(从Maven 2实例部署),verified(被核实时正确的和最终的)。 --> 

<status /> 

</distributionManagement> 

<!-- 以值替代名称,Properties可以在整个POM中使用,也可以作为触发条件(见settings.xml配置文件里activation元素的说明)。格式是<name>value</name>。 --> 

<properties /> 

</project> 
22
13
分享到:
评论
34 楼 white_crucifix 2014-09-16  
@xurping

前面4点,果然被你回避了,哎,已经不想吐槽更多

无论你恶意说我再多次的选择性失明,再多次的扣帽子,这都是滞后的。你挽救不了你回避了我对你的先发质疑。永远是回避,回避,回避,恶意反弹 
。。。。。

好了,感觉能说的也都说了,就这样,不管如何,应该都会有些收获

对方四辩辩友,你还有一次机会总结成词,可以华丽的回复我这段话,来终结讨论,加油
33 楼 xurping 2014-09-16  
white_crucifix 写道
真的要把那些我提出的而你回避掉的技术方面的提问(反问)和论点,重新罗列出来给你看,让你一条一条回答么,真的要做到这种地步么?


1.很高兴,又欣赏到你强大的给别人扣帽子的劣习(“一看就是示弱的表示”,“这就是一种欲盖弥彰的表现”)

2.突然发现你这个人还是很有意思的,讨论技术问题的时候;你不专心讨论技术问题,连别人的回复都看不全就着急回复,趾高气扬的说别人“满嘴跑火车”、“荒谬”,教育我“你谈到新手,我可以告诉你”;可是我明明已经明确的就要对你乱给别人扣帽子的恶习再踩你几脚了,你又来跟我扯什么Maven如何,“重新罗列出来给你看”;你为什么总是自我感觉良好到认为别人得回复你的所有观点呢?说你错了就得列出你满意的原因?是不是你对的就必须肯定下还有给你捧个哏?

3.不要太自恋,还“清晰和优雅是一个程序员的基本素养”呢,对不起,“如今的根生蒂固”,你把成语写错啦,不用那么着急的,要是你不急,现在的输入法应该会给你个正确的提示的。

4.对了,别忘了回答我上次的提问“全栈码农,多全的栈啊?这得是联合国认证的吗?”,否则我可要担心“你又去寻找新的素材,又出现我说你什么你又恶意反说我什么的无聊情景。”

5.嗯,也不是没有进步,你终于说对了我一次:“现在怎么做,全在你”;是的,我一直如此,不管是过去怎么做,现在怎么做,将来怎么做,都在我自己。

6,最后,现在的我,就是喜欢再问你一句:又踩到了吗?
32 楼 white_crucifix 2014-09-16  
真的要把那些我提出的而你回避掉的技术方面的提问(反问)和论点,重新罗列出来给你看,让你一条一条回答么,真的要做到这种地步么?
31 楼 white_crucifix 2014-09-16  
@xurping
的确,世界上不愿意承认错误的人不止你一个,这没什么(当然,你也可以说我,都ok)

简单总结一下你的行文论调,你开始说1+1=3,然后被我反驳了1+1=2,然后你又去寻找新的素材1+1=4,然后被我再反驳,然后你就开始各种你做过些什么呀,你有什么经验啊等等这种一看就是示弱的表示(当然你自己永远不会承认)。这种就是你就事论事?

我的“就事论事”指的是,你能说哪怕一点,能让人觉得对的技术经验?被反驳了,你就要再从技术角度反驳回来,这样才能越辩越明,互相学习。真正对的东西,一定是可以被证明的,是吧?

还有,我一说你“选择性失明”,然后你疯狂的说我选择性失明,这就是一种欲盖弥彰的表现,的确是网络争论常用的诡计,我懂。而且你忽略我的各种推断,直接给我下了个定义“随意”指责别人怎么怎么,然后我反驳了你这个说法,现在你还在说随意随意,你脑子里到底装的是什么。随意的问题你能阐述一下么?【1】

同意你一个观点,“平和”是好事。你可能觉得我言辞过于犀利,但是态度是一种扩展,是在一种正确是非观上的扩展,态度好果然好,但它永远是“理”的附属品。

我倒是忽然反应过来了,你说的踩着尾巴了,是指的态度上的变化吧,我还以为是“理”上的,那踩就踩吧,总比你“自己打自己脸好啊”。。。。一个是态度,一个是是非观,呵呵,一目了然。。。。

另外,我表示很无语,我忽略了“作为报复”么?你的逻辑到底是什么样的(对不起实在忍不住又要吐槽你的问题了), 你所谓的报复不就是问“svn和maven的关联”,我已经表达的很清楚了,而且你问我做了啥我也回答了,我真的不想再提你“选择性失明了”,这已经是逻辑能力的问题了。。。。别再说我“随意”下定论了,满满一段啊,看清楚了我倒是很好奇我说的这份上,你还要做什么狡辩?【2】

接着,有一个地方我先承认下自己的问题,24楼的回答我的确没看到,因为看到25楼你打了一大段自,所以以为下面没有了。(所以我在打很多字的时候比较习惯用@,清晰和优雅是一个程序员的基本素养)。

然后,对24楼你的说法做一个回应,2 , 3, 4点都没问题,挺好;第一点很让我叹息,其实我们说的现状很是一样的,就是用maven来管理软件生命周期,用svn管理代码版本,非常正常。你说的“我们不需对产品的源代码、产品发布做版本管理和追溯吗?”,这些不就是svn的工作范畴,和maven没有关系,只不过你现在用svn管理一个maven项目,明天你不用maven,你用svn一样是控制的“产品的源代码、产品发布做版本管理和追溯”。这两个工具的使用过程中,互相之间毫不影响啊!所以说到这个份上,我希望你思考一下,我觉得是和你的想法可能是一样的。【3】但是你的表述是不对的。

这个楼里有很多人,我们所说的每一句话,在别人那里都会有提醒,都会被看到。任何恶意的调侃,假装很惬意的措辞,在别人眼中都是会被看不起的。。。如果你觉得自己走自己的路挺好,那很ok;不然老老实实谈一下,你的使用过程中,具体哪些地方和maven产生了冲突,觉得maven做的不够的,我想对所有人都是一种学习,不管是新手还是老手,这种才叫就事论事。【4】

你现在能够让别人信服你的地方,我已经用【1】【2】【3】【4】给列出了,防止你又去寻找新的素材,防止又出现我说你什么你又恶意反说我什么的无聊情景。这4点,无论是你有好的说法或建议,亦或者是承认错误,我觉得都挺好的。不要觉得你最开始的大放厥词下不了台阶,而硬着头皮到底。我这人就是这样,如果我说错了,我会很欣然承认错误,前提是你能解释的通。

所以,现在怎么做,全在你
30 楼 xurping 2014-09-16  
xurping 写道
white_crucifix 写道


踩着尾巴了吗? 疼吗? 疼不疼的多踩两脚吧,谁叫咱高兴呢。

那么爱用CLI,还写什么《IntelliJ使用指南—— 深入理解IntelliJ的Web部署逻辑》,咋不用Maven啊?

原来Maven和SVN不应该也没必要耦合啊?小伙一直自己一个人在研究写程序吧,天才啊。

再问你一次: 你有生产环境做过开发的经验吗? 回答一下吧,免得你也被扣上“选择性失明的诡计”


再次说明了你说的越多,错误越多。

你踩着啥尾巴了?我对你的驳斥你一次也没有做过回应,不断的逃避,不断的寻找新的素材,然后被我不断的驳斥,而且你还乐在其中。真是不知道你怎么样养成的阿Q精神。哎

比如你一直强调的Maven和svn的联系。在我看来无论是GUI还是CLI,最终都是maven install,  svn commit等等,这两方面操作没有任何的关系啊。如果你不说出所谓的联系,你永远会被我压在下面。同时你的任何反问都将缺乏力道。

事实上,你已经抓狂了。。。我研究IntelliJ和tomcat的操作技巧,与Maven有半毛钱关系。。。。。
“那么爱用CLI,.....,咋不用Maven啊?”。。。。。到底想说啥 =.=
再给你致命一击,我在用intelliJ写maven管理的项目是,大部分都是用的命令行操作。。因为intelliJ内部自带了一个CLI窗口,当然像eclipse一样建立run config也是可以的。当然svn之类的涉及到大量的diff,我还是用GUI多一点,当然有时候也会用CLI

我从来不鄙视GUI,因为GUI也是某种软件自动化的体现,这是一种进步。但你千万别用GUI标榜什么,比如说“技术控"。

另外,为什么人们总是喜欢问你做过什么什么来呢,是想先评估一下对方的经验再组织回击的语句么?如果是这样,那我诚实的告诉你:
一个入门级的全栈码农,写过web(jee, nodejs,以及其他玩票性质的),写过GUI自动化测试,写过数据库相关模块,写过nosql性能测试工具,以及打过各种语言的酱油。

所以,你还是“就事论事”的从技术角度讨论某个工具的利弊?比如你遇到过什么错误等等等。少一些抽象的,定义的,调侃的措辞吧。你也不是一个新手了,成熟一点。


看来是踩着了?
1. 个人自认为为人处世是比较平和的,看看我20楼、22楼、24楼的回复那个不是就事论事?我说过你一句了没有?
2. 25楼,大部分内容是本人自我反思了一下,当然你可能没看见(不知算不算“选择性失明的诡计”);主要怪我“你有生产环境做过开发的经验吗?”这话太挑战你的神经了,其实本来也没啥意思,因为前边有句“作为报复”又被你习惯的忽略了;本来意思就是调侃下我也根据你的回复风格,随意评论一下你,看你咋说;结果我很欣慰,你的回复表明,虽然你擅长对别人随意做出更牛的评论(比如“你自己打脸打的这么响,你都没听到么?”),但你自己是万万不能被别人评论的。

3.虽然你是受不了,但我现在高兴问你啊,再问你一句,全栈码农,多全的栈啊?这得是联合国认证的吗?

29 楼 style2013 2014-09-16  
xurping 写道
white_crucifix 写道


踩着尾巴了吗? 疼吗? 疼不疼的多踩两脚吧,谁叫咱高兴呢。

那么爱用CLI,还写什么《IntelliJ使用指南—— 深入理解IntelliJ的Web部署逻辑》,咋不用Maven啊?

原来Maven和SVN不应该也没必要耦合啊?小伙一直自己一个人在研究写程序吧,天才啊。

再问你一次: 你有生产环境做过开发的经验吗? 回答一下吧,免得你也被扣上“选择性失明的诡计”


再次说明了你说的越多,错误越多。

你踩着啥尾巴了?我对你的驳斥你一次也没有做过回应,不断的逃避,不断的寻找新的素材,然后被我不断的驳斥,而且你还乐在其中。真是不知道你怎么样养成的阿Q精神。哎

比如你一直强调的Maven和svn的联系。在我看来无论是GUI还是CLI,最终都是maven install,  svn commit等等,这两方面操作没有任何的关系啊。如果你不说出所谓的联系,你永远会被我压在下面。同时你的任何反问都将缺乏力道。

事实上,你已经抓狂了。。。我研究IntelliJ和tomcat的操作技巧,与Maven有半毛钱关系。。。。。
“那么爱用CLI,.....,咋不用Maven啊?”。。。。。到底想说啥 =.=
再给你致命一击,我在用intelliJ写maven管理的项目是,大部分都是用的命令行操作。。因为intelliJ内部自带了一个CLI窗口,当然像eclipse一样建立run config也是可以的。当然svn之类的涉及到大量的diff,我还是用GUI多一点,当然有时候也会用CLI

我从来不鄙视GUI,因为GUI也是某种软件自动化的体现,这是一种进步。但你千万别用GUI标榜什么,比如说“技术控"。

另外,为什么人们总是喜欢问你做过什么什么来呢,是想先评估一下对方的经验再组织回击的语句么?如果是这样,那我诚实的告诉你:
一个入门级的全栈码农,写过web(jee, nodejs,以及其他玩票性质的),写过GUI自动化测试,写过数据库相关模块,写过nosql性能测试工具,以及打过各种语言的酱油。

所以,你还是“就事论事”的从技术角度讨论某个工具的利弊?比如你遇到过什么错误等等等。少一些抽象的,定义的,调侃的措辞吧。你也不是一个新手了,成熟一点。

  
28 楼 white_crucifix 2014-09-15  
white_crucifix 写道


踩着尾巴了吗? 疼吗? 疼不疼的多踩两脚吧,谁叫咱高兴呢。

那么爱用CLI,还写什么《IntelliJ使用指南—— 深入理解IntelliJ的Web部署逻辑》,咋不用Maven啊?

原来Maven和SVN不应该也没必要耦合啊?小伙一直自己一个人在研究写程序吧,天才啊。

再问你一次: 你有生产环境做过开发的经验吗? 回答一下吧,免得你也被扣上“选择性失明的诡计”


再次说明了你说的越多,错误越多。

你踩着啥尾巴了?我对你的驳斥你一次也没有做过回应,不断的逃避,不断的寻找新的素材,然后被我不断的驳斥,而且你还乐在其中。真是不知道你怎么样养成的阿Q精神。哎

比如你一直强调的Maven和svn的联系。在我看来无论是GUI还是CLI,最终都是maven install,  svn commit等等,这两方面操作没有任何的关系啊。如果你不说出所谓的联系,你永远会被我压在下面。同时你的任何反问都将缺乏力道。

事实上,你已经抓狂了。。。我研究IntelliJ和tomcat的操作技巧,与Maven有半毛钱关系。。。。。
“那么爱用CLI,.....,咋不用Maven啊?”。。。。。到底想说啥 =.=
再给你致命一击,我在用intelliJ写maven管理的项目是,大部分都是用的命令行操作。。因为intelliJ内部自带了一个CLI窗口,当然像eclipse一样建立run config也是可以的。当然svn之类的涉及到大量的diff,我还是用GUI多一点,当然有时候也会用CLI

我从来不鄙视GUI,因为GUI也是某种软件自动化的体现,这是一种进步。但你千万别用GUI标榜什么,比如说“技术控"。

另外,为什么人们总是喜欢问你做过什么什么来呢,是想先评估一下对方的经验再组织回击的语句么?如果是这样,那我诚实的告诉你:
一个入门级的全栈码农,写过web(jee, nodejs,以及其他玩票性质的),写过GUI自动化测试,写过数据库相关模块,写过nosql性能测试工具,以及打过各种语言的酱油。

所以,你还是“就事论事”的从技术角度讨论某个工具的利弊?比如你遇到过什么错误等等等。少一些抽象的,定义的,调侃的措辞吧。你也不是一个新手了,成熟一点。
27 楼 xurping 2014-09-15  
white_crucifix 写道


你说的越多只会暴露的越多,真的
我从来不会盲目对别人下结论,都是推断出来的,当然推断有对有错,错了你指正了,就ok了。所以,你所谓的“随意”对别人下结论,本身就是选择性失明的诡计。

“即使你用无语伦比的论证证明了我是一个开发白痴,是一个if else都写不对的弱智,也并不能证明你的Maven就是好”,
这句话是实实在在的诡辩,你自己说的就事论事,真是自己打脸。
第一,我要证明的是:你对maven的看法是很傻的。而不是证明maven到底有多牛X。
第二,你都假设自己是个开发白痴了,你觉得还有这个信心对开发工具大放厥词么?
第三,你所谓的“语无伦次”才是真正的随意下定论,你是忽略掉了我所有的推断么?你有对任何一个推断做过分析和反驳么?

“Maven有必要与SVN产生关联吗?”,maven控制的是软件生命周期(编译,测试,,打包,部署),而svn控制的软件代码的版本(提交,更新),这两者不应该也没必要耦合,我宁可熟悉这两个工具独立的CLI。

所以,你自己打脸打的这么响,你都没听到么?


踩着尾巴了吗? 疼吗? 疼不疼的多踩两脚吧,谁叫咱高兴呢。

那么爱用CLI,还写什么《IntelliJ使用指南—— 深入理解IntelliJ的Web部署逻辑》,咋不用Maven啊?

原来Maven和SVN不应该也没必要耦合啊?小伙一直自己一个人在研究写程序吧,天才啊。

再问你一次: 你有生产环境做过开发的经验吗? 回答一下吧,免得你也被扣上“选择性失明的诡计”
26 楼 white_crucifix 2014-09-15  
xurping 写道

刚才写着写着,才写了一半,一不小心发出去了;没想到,也挺好,给了自己一个思考的机会。
我在干什么呢?在做你问我答吗?在向一个如引文中红字所标的结论作斗争吗?要证明我不是一个那样的人吗?是要证明我很牛,所以我的观点自然也很牛吗?

是的,我执着了;风景好与不好,只有当自己走到了,才会做出自己的真实判断;既然是新手,既然还有时间,有兴趣去研究一个问题,作为一个先走过的人,实在没必要替别人做些千万别这么做又或千万别那么做的结论了,有心情的话,就提醒下哥是这么做的,但是碰到了这么几个问题,又是那样的解决的给后来人参考吧。

最后,还要对white_crucifix的行文表达一下强烈的不满,因为如上次回复提醒过你,不要随便对别人下结论,还是就事论事吧!否则即使你用无语伦比的论证证明了我是一个开发白痴,是一个if else都写不对的弱智,也并不能证明你的Maven就是好,就是适合新手的观点是对的!

最最后,作为报复,以及为了使自己心情畅达,抛个疑问吧:连“Maven有必要与SVN产生关联吗?”这样的话都敢问,你有生产环境做过开发的经验吗?

善哉,善哉,贫程序猿又着相了!


你说的越多只会暴露的越多,真的
我从来不会盲目对别人下结论,都是推断出来的,当然推断有对有错,错了你指正了,就ok了。所以,你所谓的“随意”对别人下结论,本身就是选择性失明的诡计。

“即使你用无语伦比的论证证明了我是一个开发白痴,是一个if else都写不对的弱智,也并不能证明你的Maven就是好”,
这句话是实实在在的诡辩,你自己说的就事论事,真是自己打脸。
第一,我要证明的是:你对maven的看法是很傻的。而不是证明maven到底有多牛X。
第二,你都假设自己是个开发白痴了,你觉得还有这个信心对开发工具大放厥词么?
第三,你所谓的“语无伦次”才是真正的随意下定论,你是忽略掉了我所有的推断么?你有对任何一个推断做过分析和反驳么?

“Maven有必要与SVN产生关联吗?”,maven控制的是软件生命周期(编译,测试,,打包,部署),而svn控制的软件代码的版本(提交,更新),这两者不应该也没必要耦合,我宁可熟悉这两个工具独立的CLI。

所以,你自己打脸打的这么响,你都没听到么?
25 楼 xurping 2014-09-15  
white_crucifix 写道
@xurping

虽然我理解你在使用工具过程中众多的的确确遇到让人心情不爽的坎,但是,上面3段话,总体来说,是一派胡言。

你第一段罗列了那么多你所谓的研究,无非就是想让别人知道你似乎懂得很多 ,但是真的是这样吗?Eclipse和maven配合使用有问题吗?Maven有必要与SVN产生关联吗?新手需要去搭建私服吗?至于JacORB,proguard,每个人术业有专攻,我的确不熟悉,不能盲目的说你是错的,但是通过你的整体表述,我只能表示“不信任”,因为第一段里故意混入了大量子虚乌有的问题。另外善意的嘲笑一下,你自称为技术控,为什么那么在意需要友好的图形化界面呢?

第二段就更荒谬了,真心不知道你用到的第三方库的开发团队有多么不认真,依赖还会写的不严谨,太可笑。在联系你前面说的引了“几百M”的库,真心觉得你满嘴跑火车啊,你去给我满世界找找有多少一个dependency lib会引出几百兆的lib。
jar包引发的问题无非三种,没有引jar包、重复jar包冲突、jar包版本偏差。这三种没有一种是maven解决不了的,不知道你说的“一旦引发问题,非常难以定位和解决”和引jar包有什么关系?

第三点,这是对新手最最错误的引导。新手如果能够尽快的适应构建工具,对于他来说只有好处没有坏处。软件行业也是与时俱进的,你看看现在各种流行的事物,python,ruby,nodejs,scala/play,甚至是Extjs -_-,哪一个没有自己的构建工具,甚至官方guide还推崇新手从构建工具开始学习,有些著名开源软件的官网已经不提供直接下载了,给你的就是maven配置。

我们学java的时代,ant都不怎么普及,所以大家并没有这方面意识。这就好比我们中国学编程的学生绝大部分都是从Windows平台开始的,而国外很多都是从小就从linux开始培养的,所以很多编程方面的意识都是潜移默化的。

如今的根生蒂固,是因为当年撒下的种子


刚才写着写着,才写了一半,一不小心发出去了;没想到,也挺好,给了自己一个思考的机会。
我在干什么呢?在做你问我答吗?在向一个如引文中红字所标的结论作斗争吗?要证明我不是一个那样的人吗?是要证明我很牛,所以我的观点自然也很牛吗?

是的,我执着了;风景好与不好,只有当自己走到了,才会做出自己的真实判断;既然是新手,既然还有时间,有兴趣去研究一个问题,作为一个先走过的人,实在没必要替别人做些千万别这么做又或千万别那么做的结论了,有心情的话,就提醒下哥是这么做的,但是碰到了这么几个问题,又是那样的解决的给后来人参考吧。

最后,还要对white_crucifix的行文表达一下强烈的不满,因为如上次回复提醒过你,不要随便对别人下结论,还是就事论事吧!否则即使你用无语伦比的论证证明了我是一个开发白痴,是一个if else都写不对的弱智,也并不能证明你的Maven就是好,就是适合新手的观点是对的!

最最后,作为报复,以及为了使自己心情畅达,抛个疑问吧:连“Maven有必要与SVN产生关联吗?”这样的话都敢问,你有生产环境做过开发的经验吗?

善哉,善哉,贫程序猿又着相了!
24 楼 xurping 2014-09-15  
white_crucifix 写道
@xurping

虽然我理解你在使用工具过程中众多的的确确遇到让人心情不爽的坎,但是,上面3段话,总体来说,是一派胡言。

你第一段罗列了那么多你所谓的研究,无非就是想让别人知道你似乎懂得很多,但是真的是这样吗?Eclipse和maven配合使用有问题吗?Maven有必要与SVN产生关联吗?新手需要去搭建私服吗?至于JacORB,proguard,每个人术业有专攻,我的确不熟悉,不能盲目的说你是错的,但是通过你的整体表述,我只能表示“不信任”,因为第一段里故意混入了大量子虚乌有的问题。另外善意的嘲笑一下,你自称为技术控,为什么那么在意需要友好的图形化界面呢?

.......
我们学java的时代,ant都不怎么普及,所以大家并没有这方面意识。这就好比我们中国学编程的学生绝大部分都是从Windows平台开始的,而国外很多都是从小就从linux开始培养的,所以很多编程方面的意识都是潜移默化的。

如今的根生蒂固,是因为当年撒下的种子。


1. Maven有必要与SVN产生关联吗? 我们不需对产品的源代码、产品发布做版本管理和追溯吗?
2. JacORB这个是有些专业了,可是这是CORBA开发世界非常有名的开源CORBA实现,作为一个第三方库的代表,个人认为也是恰当的
3. ProGuard,是压缩、优化和混淆Java字节码文件的免费的工具;大多说做过手机java开发的都用过,是用来对产品Jar包进行混淆的常用工具,实际产品中为了对产品的核心代码进行保护,是要尝尝使用的。
4. 对于“友好的图形化界面”的论述,是在条件“一个需要使用者去迁就的工具必然不是好工具”前提下的;请综合理解,不要断章取义。


23 楼 white_crucifix 2014-09-13  
@xurping

虽然我理解你在使用工具过程中众多的的确确遇到让人心情不爽的坎,但是,上面3段话,总体来说,是一派胡言。

你第一段罗列了那么多你所谓的研究,无非就是想让别人知道你似乎懂得很多,但是真的是这样吗?Eclipse和maven配合使用有问题吗?Maven有必要与SVN产生关联吗?新手需要去搭建私服吗?至于JacORB,proguard,每个人术业有专攻,我的确不熟悉,不能盲目的说你是错的,但是通过你的整体表述,我只能表示“不信任”,因为第一段里故意混入了大量子虚乌有的问题。另外善意的嘲笑一下,你自称为技术控,为什么那么在意需要友好的图形化界面呢?

第二段就更荒谬了,真心不知道你用到的第三方库的开发团队有多么不认真,依赖还会写的不严谨,太可笑。在联系你前面说的引了“几百M”的库,真心觉得你满嘴跑火车啊,你去给我满世界找找有多少一个dependency lib会引出几百兆的lib。
jar包引发的问题无非三种,没有引jar包、重复jar包冲突、jar包版本偏差。这三种没有一种是maven解决不了的,不知道你说的“一旦引发问题,非常难以定位和解决”和引jar包有什么关系?

第三点,这是对新手最最错误的引导。新手如果能够尽快的适应构建工具,对于他来说只有好处没有坏处。软件行业也是与时俱进的,你看看现在各种流行的事物,python,ruby,nodejs,scala/play,甚至是Extjs -_-,哪一个没有自己的构建工具,甚至官方guide还推崇新手从构建工具开始学习,有些著名开源软件的官网已经不提供直接下载了,给你的就是maven配置。

我们学java的时代,ant都不怎么普及,所以大家并没有这方面意识。这就好比我们中国学编程的学生绝大部分都是从Windows平台开始的,而国外很多都是从小就从linux开始培养的,所以很多编程方面的意识都是潜移默化的。

如今的根生蒂固,是因为当年撒下的种子。
22 楼 xurping 2014-09-13  
white_crucifix 写道
xurping 写道

学艺不精害死人,第一次听说maven学习曲线陡,小伙伴们都惊呆了
与ant相比,maven简直就是自动化的典范。查了一下jacORB,一共就十几M的大小,不知道你从哪个坑爹的国内博客上拷贝下来的maven配置需要download几百兆jar包。
http://ant.apache.org/contributors.html
ant的官网都是用maven生成的,还想怎么样

1.学习曲线陡不陡,从工具引入的额外概念多少知道了,看看这个Maven的完全版的配置文件,有多少标签,光了解搞明白每个标签的含义就要多长时间,更别说背后隐藏的所谓约定?
2.你真的看过maven的本地Repository缓存的大小吗?




都说到自动化了你还是无法感知哪个更容易,说明你对maven基本就是知道一个名字而已。
那就举个最粗俗的例子,你谈到新手,我可以告诉你,maven学习过程要比ant简单数倍。因为对于一个最常规的项目,maven除了引jar包,就无需其他逻辑配置了。而ant则各个方面都要配各种target,如果是新手要配好整个的build.xml需要花费大量时间学习概念和配置逻辑关系。

第二点,你对repo的理解也是有问题的,不要再把jar包当作你项目的一部分了!maven自动下载的lib包含了你项目所需的,以及maven自己运作所需的各种lib,这是一个中心,是你整个本地的中心资源区。所以几百兆完全不嫌多。因为是本地所有项目公用的。




1. 不要随便对别人下结论。作为一个技术控,本人光自己整理的Maven学习笔记就有上百页的文档,更是在实际项目开发中在使用Maven编译JacORB(涉及IDL编译、CORBA客户端服务器段代码编译打包)、如何使用Maven编译发布OSGI插件、如何在Eclipse里边结合使用Maven,使用Maven与Subversion配合管理源代码,Maven与proguard配合混淆最终Jar包、SonaType Nexus Maven私服安装使用,Eclipse Maven Plugin IAM安装使用等等深入研究后,不得不痛苦的决定不再花费过多精力在Maven上,就一个公司的相对固定的开发模式而言,花费在Maven上的精力远不如用来自己构建一个基于Ant的自动编译开发环境,简单的使用Eclipse的Ant View即可。

Maven自身的构建模型很多时候相对来说已经过于沉重了,个人认为一个需要使用者去迁就的工具必然不是好工具,特别是它再本身没有提供友好的人机交互界面的时候。
使用Ant的最大好处就是一切都是简单的、可控的。

2. 本地Repository缓存的大小 ,说真的,我也仔细研究过,这其实也是Maven的一个大问题,就是一个不严谨的库的依赖项定义,会导致Repository的疯涨;举例而言,我们依赖了一个第三方库,但它的dependency写的并不严谨,有用没有的写了一堆,反正它的编译是没有问题了,可是我们一旦依赖上它,就会导致一堆有用没用的库引入了进来,而且这一旦引发问题,非常难以定位和解决,更难以控制最终发布包的大小;此外,一个新手在命令行一敲mvn,结果发现先呼呼的下载一堆东西,还经常提示下载错误(再加上众所周知的经常国外网站不能访问),

3. 最后,对于新手们而言,其实我的建议是,Maven和Ant最好都别花费什么精力,就是说别花费精力在类似构建工具上,学习练手,用个IDE环境,比如Eclipse,足够了;真正工作后,每个优秀公司的项目组都会有自己的软件开发规范和构建规范的,到时候再学习适应也不晚,构建工作真不是每个人都需要关注的。
21 楼 white_crucifix 2014-09-12  
xurping 写道

学艺不精害死人,第一次听说maven学习曲线陡,小伙伴们都惊呆了
与ant相比,maven简直就是自动化的典范。查了一下jacORB,一共就十几M的大小,不知道你从哪个坑爹的国内博客上拷贝下来的maven配置需要download几百兆jar包。
http://ant.apache.org/contributors.html
ant的官网都是用maven生成的,还想怎么样

1.学习曲线陡不陡,从工具引入的额外概念多少知道了,看看这个Maven的完全版的配置文件,有多少标签,光了解搞明白每个标签的含义就要多长时间,更别说背后隐藏的所谓约定?
2.你真的看过maven的本地Repository缓存的大小吗?




都说到自动化了你还是无法感知哪个更容易,说明你对maven基本就是知道一个名字而已。
那就举个最粗俗的例子,你谈到新手,我可以告诉你,maven学习过程要比ant简单数倍。因为对于一个最常规的项目,maven除了引jar包,就无需其他逻辑配置了。而ant则各个方面都要配各种target,如果是新手要配好整个的build.xml需要花费大量时间学习概念和配置逻辑关系。

第二点,你对repo的理解也是有问题的,不要再把jar包当作你项目的一部分了!maven自动下载的lib包含了你项目所需的,以及maven自己运作所需的各种lib,这是一个中心,是你整个本地的中心资源区。所以几百兆完全不嫌多。因为是本地所有项目公用的。


20 楼 xurping 2014-09-12  

学艺不精害死人,第一次听说maven学习曲线陡,小伙伴们都惊呆了
与ant相比,maven简直就是自动化的典范。查了一下jacORB,一共就十几M的大小,不知道你从哪个坑爹的国内博客上拷贝下来的maven配置需要download几百兆jar包。
http://ant.apache.org/contributors.html
ant的官网都是用maven生成的,还想怎么样

1.学习曲线陡不陡,从工具引入的额外概念多少知道了,看看这个Maven的完全版的配置文件,有多少标签,光了解搞明白每个标签的含义就要多长时间,更别说背后隐藏的所谓约定?
2.你真的看过maven的本地Repository缓存的大小吗?
19 楼 white_crucifix 2014-05-23  
xurping 写道
据说Maven这工具本意是说用来提供比Ant更多的缺省约定的,看看这个配置文件就知道了,这玩意得有多复杂啊!

对新手的建议:

如果没有大把时间,还是别玩Maven了,学习曲线陡峭,收益很少。
Javaer,还是Ant吧,需要啥功能,你就现找,现学

曾经用Maven,引了一个开源库,好像是JacORB,结果本地Maven的缓存给我拖下来几百兆的库文件,唉,不说了,我的时间,我花费在Maven上的时间和买书的金钱啊。

关键是,我现在竟然不用Maven了,还是用Ant。


学艺不精害死人,第一次听说maven学习曲线陡,小伙伴们都惊呆了
与ant相比,maven简直就是自动化的典范。查了一下jacORB,一共就十几M的大小,不知道你从哪个坑爹的国内博客上拷贝下来的maven配置需要download几百兆jar包。
http://ant.apache.org/contributors.html
ant的官网都是用maven生成的,还想怎么样
18 楼 haroldshen 2014-05-23  
好文好文好文好文
17 楼 yaerfeng1989 2014-05-23  
xurping 写道
据说Maven这工具本意是说用来提供比Ant更多的缺省约定的,看看这个配置文件就知道了,这玩意得有多复杂啊!

对新手的建议:

如果没有大把时间,还是别玩Maven了,学习曲线陡峭,收益很少。
Javaer,还是Ant吧,需要啥功能,你就现找,现学

曾经用Maven,引了一个开源库,好像是JacORB,结果本地Maven的缓存给我拖下来几百兆的库文件,唉,不说了,我的时间,我花费在Maven上的时间和买书的金钱啊。

关键是,我现在竟然不用Maven了,还是用Ant。


maven是趋势,还是早点学好的。
16 楼 xurping 2014-05-23  
据说Maven这工具本意是说用来提供比Ant更多的缺省约定的,看看这个配置文件就知道了,这玩意得有多复杂啊!

对新手的建议:

如果没有大把时间,还是别玩Maven了,学习曲线陡峭,收益很少。
Javaer,还是Ant吧,需要啥功能,你就现找,现学

曾经用Maven,引了一个开源库,好像是JacORB,结果本地Maven的缓存给我拖下来几百兆的库文件,唉,不说了,我的时间,我花费在Maven上的时间和买书的金钱啊。

关键是,我现在竟然不用Maven了,还是用Ant。
15 楼 kawin_zhao 2014-05-22  
Mave入门不错哈..收藏.

相关推荐

    史上最全的maven的pom.xml文件详解

    史上最全的Maven的Pom.xml文件详解 Maven是Java领域最流行的构建工具之一,其核心配置文件是Pom.xml。在Pom.xml文件中,我们可以定义项目的基本信息、依赖关系、构建过程、测试环境等。下面,我们将详细解析Pom.xml...

    Maven pom.xml与settings.xml详解

    在Maven的世界里,`pom.xml`和`settings.xml`是两个至关重要的配置文件,它们共同决定了Maven项目的构建过程和环境配置。`pom.xml`(Project Object Model)文件是每个Maven项目的核心,它包含了项目的基本信息、...

    Maven build之pom.xml文件中的Build配置

    Maven通过一个叫做pom.xml的项目对象模型文件来配置项目构建的各个方面,其中标签是Maven构建配置的核心部分,它定义了整个构建生命周期中需要执行的指令和任务。 Maven构建包括编译代码、执行测试、打包以及部署等...

    maven的本地仓库配置文件settings.xml和项目中文件pom.xml.zip

    一、Idea关联的maven本地仓库配置...三、3个可单独使用的,maven项目文件pom.xml自定义配置 pom-maven-springboot-CusConfigV1.xml pom-maven-springboot-CusConfigV2.xml pom-maven-spring-CusConfigV1不推荐使用.xml

    maven pom.xml

    maven pom.xml详解

    maven pom.xml 详解

    maven 中 pom.xml 文件详解

    maven项目pom.xml最详细配置

    maven的pom.xml的最详细配置,内含pom的依赖、jdk配置等

    Maven的pom.xml配置文件详细配置说明

    Maven的pom.xml配置文件详细配置说明 &lt;project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=...

    maven pom.xml 动态读取变量值插件

    该jar包功能,可以在一个properties文件里面定义jdbc.url=${url},在另一个properties文件定义具体的值,通过该jar可以获取到哪个具体的值。下载之后,自行安装到本地...具体pom.xml配置使用可以参考网络其他博文,谢谢

    Maven之pom.xml配置文件详解.pdf

    本篇详解主要针对Maven中的核心配置文件——pom.xml进行深入解析,帮助理解和应用其配置。 首先,pom.xml是每个使用Maven的项目的必配文件,它位于项目的根目录下,用于定义项目的构建配置和其他信息。配置文件的...

    idea中pom.xml文件

    idea中pom.xml文件

    maven pom.xml详解

    ### Maven POM.xml 文件详解 #### 一、概述 POM (Project Object Model) 是 Maven 构建项目的核心配置文件,采用 XML 格式编写。它定义了项目的元数据、依赖关系、构建逻辑等信息。POM 文件允许开发者通过简单的...

    通过mvn命令下载pom.xml中的jar包

    首先,`pom.xml`是Maven项目对象模型(Project Object Model)的配置文件,它定义了项目的构建过程、依赖关系、项目信息等。在`pom.xml`中,开发者可以声明项目所需的外部库,Maven会自动下载这些库以满足项目构建...

    maven项目pom.xml中parent标签的使用.docx

    Maven 项目 pom.xml 文件中的 parent 标签是 Maven 项目管理依赖的核心组件之一。parent 标签的使用可以简化项目间的依赖管理,使得项目结构更加清晰、易于维护。 Maven 项目中的依赖管理 在 Maven 项目中,依赖...

    Maven -史上 最全POM.xml模板

    最全maven pom文件 功能包括 1.整合 scm(git) 、ci(hudson)、issus(trac) 2.依赖部分根据自己添加 3.build 部分,自定义目录功能 4.report整合包括:javadoc、jxr、checkstyle、pmd、changelog、emma、...

    常用pom.xml文件.zip

    本文将深入探讨Maven工程的核心配置文件——pom.xml,以及它在项目构建过程中的重要作用。 pom.xml,全称Project Object Model(项目对象模型),是Maven项目的灵魂所在。它定义了项目的元数据,包括项目信息、构建...

    MAVEN pom.xml 配置oracle driver jar

    本主题将深入探讨如何在Maven的配置文件`pom.xml`中添加Oracle数据库驱动(jar)以实现与Oracle数据库的连接。首先,我们需要理解`pom.xml`文件的作用,它是Maven项目的元数据文件,包含了项目的信息、构建指令以及...

    pom.xml android maven 工程

    pom.xml android maven 工程 如何拿Maven 构建 一个 Android 项目的pom配置

    maven的pom.xml说明详解

    -打包文件前置.xml- -全局属性配置- -NJCC开发环境(MySQL)- -部署环境(对应配置文件版本)- -设置默认环境- -NJCC开发环境(Oracle)- -部署环境(对应配置文件版本)- -配置maven地址- -外网- -版本增加- -表示test...

Global site tag (gtag.js) - Google Analytics