简体   繁体   English

将exec-maven-plugin从1.1.1升级到1.2或1.3.2

[英]Upgrading exec-maven-plugin from 1.1.1 to 1.2 or 1.3.2

I am running an application using exec-maven-plugin version 1.1.1. 我正在使用exec-maven-plugin版本1.1.1运行应用程序。 This is the pom config 这是pom配置

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.1.1</version>    
    <executions>
        <execution>
            <phase>install</phase>
            <goals>
                <goal>java</goal>
            </goals>
            <configuration>
                <mainClass>com.org.dc.dcClient</mainClass>
            </configuration>
    </execution>
</executions>

This has worked fine. 这很好。 I recently updated some components and it now runs properly but gets blocked at the end and won't complete (the code completes but maven doesn't finish). 我最近更新了一些组件,现在它可以正常运行,但最终被阻塞,无法完成(代码完成,但maven尚未完成)。

I have googled a bit and I think this is a bug ? 我用谷歌搜索了一下,我认为这是一个错误? I have 2 questions if anyone has the time to answer 如果有人有时间回答,我有两个问题

1) has this been fixed anywhere or should I try to convert it to cargo or Ant (I am running on windows) 1)此问题是否已在任何地方修复,还是应该尝试将其转换为货物或蚂蚁(我在Windows上运行)

2) I have tried upgrading to the more recent 1.3.2 but this doesn't work. 2)我尝试升级到最新的1.3.2,但这不起作用。 I can't see anything obvious in the log files but the app is return an http 500 response. 我在日志文件中看不到任何明显的东西,但是该应用程序返回了HTTP 500响应。 I have essentially just changed the 1.1.1 to 1.3.2 but I can't see anything in the documentation which implies I need to do anything else ? 我实际上只是将1.1.1更改为1.3.2,但是我在文档中看不到任何内容暗示我需要做其他事情吗? I'm still flapping about in this area a bit but presumably as this is a maven plug in there probably isn't a dependency conflict ? 我仍然在这方面四处游荡,但大概是因为这是一个Maven插件,可能没有依赖冲突吗?

I'm using Maven 3.2.1 and JDK 1.7 by the way. 顺便说一下,我正在使用Maven 3.2.1和JDK 1.7。

Thanks. 谢谢。

In response to comment 回应评论

What I'm trying to do - I inherited this code that had developed from a proof of concept to a bit of code run on a live build server. 我想做的是-我继承了这段代码,它从概念验证发展为在实时构建服务器上运行的一些代码。 I want to upgrade elastic search with minimal effort for now as I've just taken it on and have a few things to do (hasn't everyone!). 我现在想以最小的努力来升级弹性搜索,因为我刚刚开始做并有几件事要做(不是所有人!)。 I want the app itself to run from the command line (via jenkins) and close when it has finished. 我希望应用程序本身从命令行运行(通过jenkins)并在完成后关闭。 I guess partly I'm just being stubborn now and wanting to know what the problem with upgrading to 1.3.2 is and partly I'm not sure what the best solution to the fundamental problem of the exec-maven not releasing the process son completion. 我想部分原因是我现在很固执,想知道升级到1.3.2的问题是什么,部分原因是我不确定执行Maven基本问题而不释放流程完成的最佳解决方案是什么? 。 That being said I'm beginning to think moving it to the antrun plugin will be quicker and simpler as this seems to be a solution suggested for the underlying problem (both in the other comment and on a google search) that the 1.1.1 version (and very possibly 1.3.2 version) of exec-maven doesn't release at the end of processing). 话虽如此,我开始认为将其移至antrun插件会更快,更简单,因为这似乎是针对1.1.1版本的基本问题(在其他评论中和在Google搜索中)建议的解决方案。 (很可能是1.3.2版本)的exec-maven不会在处理结束时发布。

In terms of the log file I'm not sure how much you would like to see as obvioulsy they are massive. 就日志文件而言,我不确定您是否想看到它们太大了。 When using version 1.1.1 I get (mostly output messages I've put in ... 使用1.1.1版时,我得到了(主要是我输入的输出消息...

New 8080 server set to go
New 8080 server set
Context set
Using war file: target/dc.war
Waiting for startup...
Request Set
execute run
200
Startup complete.
.. app starts 

when I change the version to 1.3.2 I get 当我将版本更改为1.3.2时,我得到

New 8080 server set to go
New 8080 server set
Context set
Using war file: target/dc.war
Waiting for startup...
Request Set
execute run
500
...

...
Waiting for startup...
Request Set
execute run
500
[WARNING] 
java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: Server failed to start up in 60 seconds
    at com.org.dcapp.dcclass.startServer(dcclass.java:138)
    at com.org.dcapp.dcclass.main(dcclass.java:30)
    ... 6 more
[DEBUG] joining on thread Thread[qtp1062658514-33-selector-   ServerConnectorManager@b8e088e/0,5,com.org.dcapp.dcclass]

Let me know if you want more. 让我知道您是否想要更多。

Thanks 谢谢

Apologies to put this as an answer if that is the wrong format - which it probably is. 抱歉,如果格式错误-可能是这样。

On further painful investigation and going back to basics (where I should have started) I have realised the actual issue is a JSP issue brought about by upgrading from jetty 6 to jetty 9. Oddly it still seemed to work with exec-maven-plugin version 1.1.1 but failed with later versions. 经过进一步的痛苦调查并回到基础(我应该从那里开始)开始,我已经意识到实际的问题是从码头6升级到码头9带来的JSP问题。奇怪的是,它似乎仍然可以与exec-maven-plugin版本一起使用1.1.1,但在更高版本中失败。 I assume this is a dependency thing but it's over my pretty little head. 我认为这是一个依赖项,但这已经超出了我的头脑。 What I noticed is that when I switched to Ant-run I got the same 503 issue. 我注意到的是,当我切换到Ant-run时,我遇到了相同的503问题。

I noticed this thread - How do you get embedded Jetty 9 to successfully resolve the JSTL URI? 我注意到了这个线程- 您如何嵌入Jetty 9才能成功解析JSTL URI? and swapped out 换出

  <dependency>
        <groupId>org.eclipse.jetty</groupId>
        <artifactId>jetty-jsp</artifactId>
        <version>${jetty.version}</version>
    </dependency>

for 对于

 <dependency>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jsp-2.1-glassfish</artifactId>
        <version>2.1.v20100127</version>
 </dependency>

and I no longer get the 503 errors. 而且我不再遇到503错误。 Apologies in asking the question I completely missed the root cause. 向我道歉的道歉我完全没有找到根本原因。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM