网站建设500元,技术支持 佛山网站建设,购物网站排名大全,自己建一个简单的网站Apache Maven很简单#xff0c;但是功能非常强大。 使用一些技巧#xff0c;您可以大大简化和优化您的开发经验。 处理多个非托管模块 假设您有一个主项目A提供了两个实用程序模块foo和bar #xff0c;另一个项目B A了foo和bar 。 在使用B #xff0c;您意识到需要偶尔对… Apache Maven很简单但是功能非常强大。 使用一些技巧您可以大大简化和优化您的开发经验。 处理多个非托管模块 假设您有一个主项目A提供了两个实用程序模块foo和bar 另一个项目B A了foo和bar 。 在使用B 您意识到需要偶尔对foo和bar进行一些调整。 但是由于它们在不同的项目中因此通常需要 切换到A 做出改变 mvn install 切换回B 和“刷新”依赖项如果您使用的是IDE。 每次都需要进行上游更改。 使用Maven您可以使用模拟主POM临时“合并”这三部分该主POM将foo bar和B定义为子模块 project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancexsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsdmodelVersion4.0.0/modelVersion!-- blah blah blah --modulesmodulefoo/modulemodulebar/modulemoduleB/module/modules对我有什么用 IDE如IntelliJ IDEA 会将根标识为多模块项目。 这意味着您将能够 从一个模块无缝浏览到另一个模块。 不再需要反编译字节码不兼容或源映射 在“综合”项目范围内搜索某种类或方法的用法或重构其中一种方法时非常方便。 在同一项目窗口中按需修改每个模块的源和资源。 IDE将自动重新编译所做的更改并将所有内容添加到运行时类路径中。 方便进行带热重装的IDE测试和调试。 版本无缝。 如果这三个模块位于不同的VCS根目录下则IDEA如IDEA将分别跟踪每个存储库。 如果您提交了一组更改则每个存储库都会有一个新的提交以反映其自己的更改部分 都带有相同的消息 同时如果构建了根模块那么普通的Maven将按照适当的顺序构建foo / bar和B 如果需要这正是我们想要的。 相对路径FTW 即使模块分散在整个文件系统中Maven仍可以通过相对路径轻松解决它们 modulesmodule../foo/modulemodulegrandpa/papa/bar/modulemodule../../../../../media/disk2/repos/top-secret/B/module/modules放下那 也许最常用因此最被滥用 的Maven命令是 mvn clean install 在您对项目进行一些更改后事实上的事实便会运行。 而且在大多数情况下这简直是过分杀伤力。 从头开始 该命令结合了两个生命周期阶段 – Maven构建过程的“阶段”。 阶段具有确定的顺序 因此如果您请求某个阶段运行则其生命周期中的所有先前阶段都将在此阶段之前运行。 但是如果Maven插件发现自己无事可做那么他们就足够聪明地跳过工作。 例如如果编译的类是最新的则不会进行编译。 现在 clean不再是默认生命周期的一部分 而是通过删除整个target目录从头开始。 另一方面 install几乎快结束了就在默认生命周期中进行deploy之前。 mvn clean install将同时运行这两个阶段 而且由于clean 介于两者之间的所有事物也同样如此 。 当您想要清理所有内容并最终将最新的工件安装到本地 Maven存储库中时它很方便。 但是在大多数情况下您并不需要所有这些。 此外 install最终会使您的本地Maven缓存混乱 特别是如果您经常使用MB或GB大小的捆绑包进行快照/发布。 只做必要的事情 如果您更新了一个源文件并希望将其传播到target/classes目录 mvn compile Maven将自动检测任何更改–如果没有更改则完全跳过编译。 如果更改是在测试类或资源中 mvn test-compile 将其放入target/test-classes 。 只是为了运行测试它将自动编译任何脏的源代码/测试类 mvn test 要获得target最终捆绑包的副本 mvn package 由于您可能经常要在包装之前先从干净的表盘开始 mvn clean package 同样只需指定结束阶段即可 或同时包含开始和结束目标如果要在某种程度上保持清洁。 您将节省大量时间处理能力和脾气。 同时在生产中… 如果您当前的版本可以投入生产只需忘记上面的大部分内容即可 mvn clean package 虽然任何“子命令”在理论上都应该做同样的事情但是您不想冒险 虽然我使用上面的package 但从某种意义上说 install也会更好。 因为这样您将在.m2/repository中拥有生产工件的副本–如果丢失了已交付/部署的副本则可能会节省很多时间。 更多跳过… --no-snapshot-updates 如果您仔细观察了一个涉及快照依赖项的构建您会发现它花了几秒钟的时间来搜索快照的Maven元数据文件并最终以警告告终除非您习惯于将快照工件发布到远程。 如果您还本地建立快照依赖关系那么通常这没有用因此可以通过--no-snapshot-updates或-nsu参数禁用元数据检查和快照同步尝试。 当然 -o将阻止所有远程同步 但是如果您确实想提取某些依赖项则不能使用它在这种情况下 -nsu会有所帮助。 您可以跳过编译 像著名的 -Dmaven.test.skip –或-DskipTests 您可以通过-Dmaven.main.skip跳过编译步骤即使代码有所更改。 当您只想运行测试而无需花费编译开销时非常方便 当然如果您知道这些内容已经被编译。 就像-DskipTests一样-但是-DskipTests 对此SO帖子表示敬意 延续 您可能已经知道如果模块在构建过程中发生故障则可以通过-rf :module-name参数从该点恢复构建。 此参数也可以立即使用。 它不仅限于故障场景。 如果您有30个模块但是只想构建最后5个模块则可以使用-rf :name-of-26th-module 。 美味的测试技巧 继承测试 通常Maven工件不包括测试类/资源。 但是在某些情况下您希望将一些基本测试类继承到子模块中。 使用测试罐说明符您可以继承仅包含测试类和资源的工件 dependencygroupIdcom.acme/groupIdartifactIdfoo/artifactIdversion3.2.1/versiontypetest-jar/typescopetest/scope/dependency “从属”模块上的相应构建配置如下 buildpluginsplugingroupIdorg.apache.maven.plugins/groupIdartifactIdmaven-jar-plugin/artifactIdexecutionsexecutiongoalsgoaltest-jar/goal/goals/execution/executions/plugin/plugins/build 一个警告是在此过程中不会继承可传递测试依赖项而必须在每次使用测试JAR时再次手动指定它们。 至少我没有遇到更好的选择。 如果您正在处理一个测试用例请不要全部运行。 -Dtestcom.acme.my.pkg.Test可以单独进行WIP测试因此可以节省大量时间。 根据您的测试运行程序 -Dtest 也可能支持通配符选择器 。 当然您可以临时修改测试插件配置的或数组例如SureFire 以限制可运行测试的集合。 调试它 调试Maven测试 如果您的测试运行程序例如SureFire允许您自定义用于测试的命令行或JVM参数则可以轻松地将派生的JVM配置为在测试开始执行之前等待调试器 buildpluginManagementpluginsplugingroupIdorg.apache.maven.plugins/groupIdartifactIdmaven-surefire-plugin/artifactId!-- ... --configurationargLine-Xdebug -Xnoagent -Xrunjdwp:transportdt_socket,servery,address8000/argLine调试Maven本身 如果您正在编写或对Maven插件或扩展进行故障排除则在调试模式下运行Maven本身会很方便。 Maven最终是Java因此您可以简单地调用调用时运行的最终命令然后使用-Xdebug …params重新运行它。 但是Maven已经有了一个更酷的mvnDebug命令可以自动为您执行此操作。 它的语法与mvn相同因此非常容易习惯。 调用后默认情况下它将在端口8000上侦听调试器并在连接一个端口后立即开始执行 并在断点处停止显示内部状态允许表达式求值等。 看日志 这是值得的因为我们非常善于忽略事物-就在眼前。 就在一开始 我敢打赌在构建开始时Maven会有95的机会喷出至少一个[WARNING] 。 虽然我们几乎总是忽略或“推迟”它们但它们会在将来的某个时刻咬人。 即将结束 如果出现编译测试或其他故障Maven将尝试通过转储上下文stacktraces [ERROR]等来提供帮助。 有时您需要向后滚动一到两页才能找到实际的内容因此不要在第一次尝试时就放弃并砸在脸上。 最近我花了将近一个小时的时间来弄清楚-rf :原因-rf : d build失败 从头开始时同一件事成功了。 最后它systemPath关于systemPath依赖项解决错误的两行[WARNING]小systemPath 。 就在我眼前却如此无形。 绝望的时光 在某些情况下标准的Maven输出无法查明问题在跟踪模式 -X 中运行Maven是最佳做法。 尽管其输出可能令人生畏但它包含Maven以及您在构建过程中需要了解的所有内容。 插件版本编译/测试依赖树外部命令调用例如测试 这样您就可以深入挖掘并找到罪魁祸首。 一如既往耐心是一种美德。 最后的话 就像使用Maven一样 知道你在做什么。 知道你真正想做什么。 相信Maven可以做到 除非另有证明 翻译自: https://www.javacodegeeks.com/2018/11/additions-bag-maven-fu.html
