使用 maven3 加速开发
到目前为止,我找到了两种使用 maven3 运行程序的方法:
$ mvn exec:exec -Dexec.args='...'
$ mvn assembly: assembly && java -cp all-with-dependecies.jar example.Main ...
前者使用 mvn 的 JVM,它会捕获异常并且启动速度非常慢。后者也非常慢,因为它必须构建一个大罐子并运行测试。
我想要类似 $ mvncompile && java -cp $CLASSPATH 示例.Main
.由于通常 CLASSPATH 在运行之间是恒定的,因此我只需担心一次。
我的问题是如何在开发周期中加快编译、编译、测试的速度?
Until now I found two ways to run my program with maven3:
$ mvn exec:exec -Dexec.args='...'
$ mvn assembly:assembly && java -cp all-with-dependecies.jar example.Main ...
The former uses mvn's JVM which traps exceptions and starts very slow. The later is very slow too because it has to build a big jar and to run tests.
I would something like $ mvn compile && java -cp $CLASSPATH example.Main
. Since usually CLASSPATH
is constant between runs I have to worry about it only once.
My question is how do you speed up compile in the development cycle change, compile, test?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
您可以尝试 Maven Shell。简介是这样说的:
You could try the Maven Shell. The blurb says this:
您可以使用 Maven 依赖插件 构建类路径,然后重用它:
You can build a classpath with Maven Dependency Plugin, and then reuse it:
减少使用 mvn 命令行的频率,而使用诸如 Eclipse 之类的 IDE 来快速测试增量更改。
Eclipse 是增量构建的,即它只构建更改,因此速度要快得多。
Use mvn command-line less frequently, and instead use an IDE like Eclipse for quickly testing out incremental changes.
Eclipse builds incrementally i.e. it builds only changes, so is much faster.
您可以通过传递选项来跳过测试:
-Dmaven.test.skip=true
。为什么您认为启动新的 JVM 会比在 Maven 的 JVM 中运行程序更快?更有可能的是恰恰相反。
编辑:加快开发周期的另一种简单方法:使用
--offline
选项,除非您更改依赖项。You can skip the tests by passing the option:
-Dmaven.test.skip=true
.And why do you assume that starting a new JVM will be quicker than running the program within Maven's JVM? It's more likely to be just the opposite.
EDIT: another easy way to speed up the development cycle: use the
--offline
option, except when you're changing the dependencies.上次我创建命令行工具时,我使用依赖插件将所有依赖jar复制到一个目录(例如target/dist/lib),在Manifest文件(Maven Jar Plugin)中配置类路径和主类。然后我可以使用以下命令执行应用程序:
java -jar myJar.jar
The last time I created a command line tool, I used the dependency plugin to copy all dependency jars to a directory (e.g. target/dist/lib), configured the classpath and main class in the Manifest file (Maven Jar Plugin). Then I could execute the app with:
java -jar myJar.jar
除了 Eclipse 之外的另一个选择是使用 JRebel ,它将有效地热交换您的代码,以便您可以保留您的程序一直在运行。
不幸的是 JRebel 不是免费的,除非你开源或使用 Scala。
如果您使用 Eclipse(或 IntelliJ)并在调试模式下运行程序,您也可以与代码进行热交换,但不能添加或删除方法。
我发现如果您想要立即反馈,这两种方法在 Java 环境中是最有效的。
最后一个选项是配置 Maven 使用 Eclipse 编译器< /a> (据说)比 openjdk 编译器更快。
The other option besides Eclipse is to use JRebel which will effectively hot swap your code so you can keep your program running all the time.
Unfortunately JRebel is not free unless your opensource or using Scala.
If you use Eclipse (or IntelliJ) and run your program in Debug Mode you can also hot swap with your code but you can't add or delete methods.
I found these two methods to be the most productive in Java environment if you want immediate feedback.
One final option is to configure Maven to use the Eclipse compiler which is faster (supposedly) than the openjdk compiler.
如果您需要实现命令行工具,只需查看 maven appassembler 插件n 在这种情况下非常有帮助。与 maven- assembly 相关,您可以创建一个 .tar.gz/zip 存档,可以解压该存档并可以启动应用程序。
If you need to implement a command line tool just take a look to the maven appassembler plugin which is very helpful in this kind of situations. In relationship with maven-assembly you can create a .tar.gz/zip archive which can be decompressed and the application can be started.
创建一个小型共享配置并将其解压缩在每个模块中构建时的模块(检查样式配置、日志配置等)
将 Maven 插件放入其可以根据需要及时引入自己的个人配置文件,例如检查样式、findbugs、JavaDoc、surefire、故障安全、代码签名等。您的正常构建应该使用尽可能少的插件,因为这确实有助于故障排除。任何插件都可以使用 -P 命令行选项单独启用
避免编译器插件上的分叉配置,它可以使构建时间加倍。如果您需要 -parameters,那么只需为需要它的类分叉一次。
编写测试以便它们可以并行运行。任何测试都不应超过一秒。
使用 -T 1C 选项并行构建
使用嵌入式版本的 tomcat,而不是 tomcat 插件,启动 tomcat 进行集成测试。避免多次启动 tomcat。
排除任何不需要在 tomcat 配置属性中扫描的 jar。
将您的项目构建为平衡树,将相关组件分组到其自己的父 pom 下。
最上面是你的BOM POM模块、共享资源模块、共享构建路径模块。一旦你把一切都组织起来,你就很少构建这些。
接下来是您的顶级应用程序 pom,其中包括以下父 pom -
没有依赖项的常见低级模块。
-网关模块,包括http客户端库和接口模块。
- 业务服务模块
- 容器 - tomcat、Spring、DropWizzard 等。
-Packages - ubber jar、zip
-Runtimes - Rpm、可执行 jar
Poms 依赖项应始终指向更高级别的 poms,以避免循环依赖
较慢的构建工件应放在最后,这样您就可以工作而不必等待缓慢的打包。
您应该能够在大约 5 秒内构建任何组,在 5 秒内构建您的 war,在 10 秒内启动带有 spring 的 tomcat,最坏的情况是 20 秒迭代。
maven 编译器是快速且增量的,因此请尽量避免生成任何强制重新编译的代码
创建一个用于测试的小型 DSL 和解释器。我们已经看到这种方法的运行速度是 junit 的两倍。
我刚刚使用这些技术将我们的大型完整构建从 5 分钟缩短到 45 秒。这是很多工程,但值得。这种方法与标准 Maven 发布插件配合使用,使故障排除变得更加容易。
祝你好运。
它永远不够快
PS PCIe SSD 也有很大帮助
Create a single module for all your build time dependencies (annotations, embedded tomcat, code generators, etc. Build this once and attach to the compiler plugin so they are on the build path for all modules
create a small shared config and unzip it in each module at build time (check style config, logging config, etc)
place maven plugins into their own individual profiles that can be brought in just-in-time as needed. Eg check style, findbugs, JavaDoc, surefire, failsafe, code signing, etc. Your normal build should use as few plugins as possible. This really helps with troubleshooting since any plugin can be individually enabled with a -P command line option
avoid the fork config on the compiler plugin, it can double your build time. If you need -parameters then only fork once for the classes that need it.
write tests so they can run in parallel. No test should take more than a second.
use the -T 1C option to build in parallel
use the embedded version of tomcat, instead of the tomcat plugin, for launching tomcat for integration tests. Avoid starting tomcat more than once.
exclude any jars that don't need to be scanned in tomcat config properties.
structure your project into a balanced tree grouping related components under their own parent pom.
The very top is your BOM POM module, shared resource module, shared build path module. You rarely build these once you get everything organized.
Next is your top app pom that includes the following parent poms
-Common low-level modules with no dependencies.
-Gateway module that includes http client libs and interface modules.
-Biz service modules
-Containers - tomcat, Spring, DropWizzard,Etc.
-Packages - ubber jars, zips
-Runtimes - Rpms, executable jars
Poms dependencies should always point to higher level poms to avoid circular dependencies
The slower build artifacts should be last so you can work without having to wait on slow packaging.
You should be able to build any group in about 5 seconds, build your war in 5 seconds, start tomcat with spring in 10 seconds for a worst case of 20 second iteration.
the maven compiler is fast and incremental, so try to avoid generating any code that forces a recompile
create a small DSL and interpreter for your tests. We've seen this approach run twice as fast as junit.
I just took our large full build from 5 minutes to 45 seconds using these techniques. It is a lot of engineering, but worth it. This approach works with the standard maven release plugin and makes troubleshooting much easier.
Good luck.
It's never fast enough
PS PCIe SSDs are a big help too