将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

问题描述

我正在使用exec-maven-plugin版本1.1.1运行应用程序.这是pom配置

I am running an application using exec-maven-plugin version 1.1.1. This is the pom config

<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>

这很好.我最近更新了一些组件，现在它可以正常运行，但是最后被阻塞，无法完成(代码完成，但maven尚未完成).

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).

我已经用Google搜索了一下，我认为这是一个bug?如果有人有时间回答

I have googled a bit and I think this is a bug ? I have 2 questions if anyone has the time to answer

1)此问题是否已在任何地方修复，还是应该尝试将其转换为货物或蚂蚁(我在Windows上运行)

1) has this been fixed anywhere or should I try to convert it to cargo or Ant (I am running on windows)

2)我尝试升级到最新的1.3.2，但这不起作用.我在日志文件中看不到任何明显的东西，但是该应用程序返回了HTTP 500响应.我实际上只是将1.1.1更改为1.3.2，但是我在文档中看不到任何内容，这意味着我需要做其他事情吗?我仍然在这方面四处游荡，但大概是因为这是一个Maven插件，可能没有依赖冲突?

2) I have tried upgrading to the more recent 1.3.2 but this doesn't work. I can't see anything obvious in the log files but the app is return an http 500 response. 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 ? 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 3.2.1和JDK 1.7.

I'm using Maven 3.2.1 and JDK 1.7 by the way.

谢谢.

回应评论

我正在尝试做的- 我继承了该代码，该代码已从概念验证发展为在实时构建服务器上运行的一些代码.我现在想以最小的努力来升级弹性搜索，因为我刚刚开始做并有几件事要做(不是所有人！).我希望应用程序本身从命令行运行(通过jenkins)并在完成后关闭.我想部分原因是我现在很固执，想知道升级到1.3.2的问题是什么，部分原因是我不确定执行器未解决的根本问题的最佳解决方案是什么? .话虽如此，我开始认为将其移至antrun插件会更快，更简单，因为这似乎是针对1.1.1版本的基本问题(在其他评论中和在Google搜索中)建议的解决方案. (很可能是1.3.2版本)的exec-maven不会在处理结束时发布.

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. 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. 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).

就日志文件而言，我不确定您希望看到多少它们是庞大的.使用1.1.1版时，我得到了(主要是输出的消息已放入...

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 ...

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 

当我将版本更改为1.3.2时

when I change the version to 1.3.2 I get

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.

谢谢

推荐答案

如果格式错误(可能是这样)，请将其作为答案.

Apologies to put this as an answer if that is the wrong format - which it probably is.

在进一步的痛苦调查中，并回到了基础知识(我应该从这里开始)，我已经意识到实际的问题是从码头6升级到码头9所带来的JSP问题.奇怪的是，它似乎仍然可以与exec-maven一起使用-plugin 1.1.1版，但在更高版本中失败.我认为这是一个依赖项，但这已经超出了我的小脑袋.我注意到的是，当我切换到Ant-run时，我遇到了同样的503问题.

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. 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.

我注意到了这个线程-

I noticed this thread - How do you get embedded Jetty 9 to successfully resolve the JSTL URI? and swapped out

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

对于

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

，我不再遇到503错误.道歉，我完全没有找到根本原因.

and I no longer get the 503 errors. Apologies in asking the question I completely missed the root cause.

这篇关于将exec-maven-plugin从1.1.1升级到1.2或1.3.2的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！