Jetty

jetty-maven-plugin executes lifecycle phases twice, as part of a pom.xml build

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 7.5.0, 7.6.0
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

Bob Fields BobFieldsFB@hotmail.com 2011-04-12 17:21:26 EDT

Build Identifier: maven-jetty-plugin 7.2.2.v20101205 on maven 2.2.1, not using
Eclipse

When running maven-jetty-plugin as a plugin in a project pom.xml for an
integration test, all phases through test-compile are run twice because the
lifecycle is forked for the run, run-war, run-exploaded and deploy-war goals.
At best this is annoying, at worst this can result in duplicate generated key
values or buildId or other failures. As with source and many many other maven
plugins, a separate goal such as run-no-fork could be provided for each which
is delegates to the current goal except that the lifecycle phase is not invoked
as part of the execution, i.e. like
http://maven.apache.org/plugins/maven-source-plugin/test-jar-no-fork-mojo.html.
Or provide a configuration value with <fork>true</fork> as the default, such as
with the maven-compiler-plugin. There is no workaround - the previous lifecycle
phases are either executed twice, or not at all.

Reproducible: Always

Steps to Reproduce:
1. pom.xml which invokes jetty:run, i.e. as shown in
http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin
2. Run pom.xml. compile, resources phases are executed twice
3. See http://stackoverflow.com/questions/4526773/maven-jetty-plugin-question
for a specific configuration example

  1. XML File
    pom.xml
    19/Dec/11 12:21 PM
    2 kB
    Antti Andreimann

Activity

Ascending order - Click to sort in descending order
Michael Gorovoy made changes -
Field Original Value New Value
Assignee Michael Gorovoy [ mgorovoy ]
Hide
Permalink
Michael Gorovoy added a comment -

I just tried the configuration example that you provided with the jetty-maven-plugin v7.5.0-SNAPSHOT, and it does not appear to exhibit this behavior.

Please let us know if you could reproduce the issue, and we will re-open the ticket.

Show
Michael Gorovoy added a comment - I just tried the configuration example that you provided with the jetty-maven-plugin v7.5.0-SNAPSHOT, and it does not appear to exhibit this behavior. Please let us know if you could reproduce the issue, and we will re-open the ticket.
Michael Gorovoy made changes -
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 7.5.0 [ 17463 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Antti Andreimann added a comment - - edited

A minimal POM showing the problem.

Running like this:

mvn 2>&1 | grep 'default-'

Will yield the following result:

[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ jetty-run-forked-lc-demo ---
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ jetty-run-forked-lc-demo ---
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ jetty-run-forked-lc-demo ---
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ jetty-run-forked-lc-demo ---
[INFO] --- maven-surefire-plugin:2.7.2:test (default-test) @ jetty-run-forked-lc-demo ---
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ jetty-run-forked-lc-demo ---
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ jetty-run-forked-lc-demo ---
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ jetty-run-forked-lc-demo ---
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ jetty-run-forked-lc-demo ---
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ jetty-run-forked-lc-demo ---
Show
Antti Andreimann added a comment - - edited A minimal POM showing the problem. Running like this: mvn 2>&1 | grep ' default -' Will yield the following result: [INFO] --- maven-resources-plugin:2.4.3:resources ( default -resources) @ jetty-run-forked-lc-demo --- [INFO] --- maven-compiler-plugin:2.3.2:compile ( default -compile) @ jetty-run-forked-lc-demo --- [INFO] --- maven-resources-plugin:2.4.3:testResources ( default -testResources) @ jetty-run-forked-lc-demo --- [INFO] --- maven-compiler-plugin:2.3.2:testCompile ( default -testCompile) @ jetty-run-forked-lc-demo --- [INFO] --- maven-surefire-plugin:2.7.2:test ( default -test) @ jetty-run-forked-lc-demo --- [INFO] --- maven-war-plugin:2.1.1:war ( default -war) @ jetty-run-forked-lc-demo --- [INFO] --- maven-resources-plugin:2.4.3:resources ( default -resources) @ jetty-run-forked-lc-demo --- [INFO] --- maven-compiler-plugin:2.3.2:compile ( default -compile) @ jetty-run-forked-lc-demo --- [INFO] --- maven-resources-plugin:2.4.3:testResources ( default -testResources) @ jetty-run-forked-lc-demo --- [INFO] --- maven-compiler-plugin:2.3.2:testCompile ( default -testCompile) @ jetty-run-forked-lc-demo ---
Antti Andreimann made changes -
Attachment pom.xml [ 58252 ]
Hide
Permalink
Antti Andreimann added a comment - - edited

This behaviour is expected since jetty:run is supposed to be used manually. The file JettyRunMojo.java uses following annotations:

JettyRunMojo.java

 * @goal start
 * @requiresDependencyResolution compile+runtime
 * @execute phase="test-compile"
 * @description Runs jetty directly from a maven project

@execute causes a lifecycle fork and everything up to test-compile will be executed

However it would be nice if an alternative goal existed that could be used in builds. Something like this:

JettyStartMojo.java
/**
 ...
 * @goal start
 * @phase pre-integration-test
 * @requiresDependencyResolution compile+runtime
 * @description Runs jetty from a maven project but does not block and will
 * not fork a parallel lifecycle. This goal should be preferred over
 * run for fully automatic testing during builds.
 */
public class JettyStartMojo extends JettyRunMojo
{
    /*
     ....
     * 
     * @parameter expression="${jetty.daemon}" default-value="true"
     */
    protected boolean daemon;
}
Show
Antti Andreimann added a comment - - edited This behaviour is expected since jetty:run is supposed to be used manually. The file JettyRunMojo.java uses following annotations: JettyRunMojo.java * @goal start * @requiresDependencyResolution compile+runtime * @execute phase= "test-compile" * @description Runs jetty directly from a maven project @execute causes a lifecycle fork and everything up to test-compile will be executed However it would be nice if an alternative goal existed that could be used in builds. Something like this: JettyStartMojo.java /** ... * @goal start * @phase pre-integration-test * @requiresDependencyResolution compile+runtime * @description Runs jetty from a maven project but does not block and will * not fork a parallel lifecycle. This goal should be preferred over * run for fully automatic testing during builds. */ public class JettyStartMojo extends JettyRunMojo { /* .... * * @parameter expression= "${jetty.daemon}" default -value= " true " */ protected boolean daemon; }
Jan Bartel made changes -
Resolution Fixed [ 1 ]
Status Resolved [ 5 ] Reopened [ 4 ]
Assignee Michael Gorovoy [ mgorovoy ] Jan Bartel [ janb ]
Hide
Permalink
Jan Bartel added a comment -

Created a new "start" goal as suggested that does not invoke a parallel lifecycle. This goal should only be used via execution bindings in pom.xml, or at the command line as "mvn jetty:start" ONLY if you know that all necessary generated files and classes are already present.

Jan

Show
Jan Bartel added a comment - Created a new "start" goal as suggested that does not invoke a parallel lifecycle. This goal should only be used via execution bindings in pom.xml, or at the command line as "mvn jetty:start" ONLY if you know that all necessary generated files and classes are already present. Jan
Jan Bartel made changes -
Status Reopened [ 4 ] Resolved [ 5 ]
Fix Version/s 7.6.0 [ 17652 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Antti Andreimann added a comment -

Thank you. 

 @execute phase="validate"

Seems a bit hackish (it technically still forks a lifecycle which only performs a project validation task), however I think it's a neccessary evil unless most of the code in JettyRunMojo is moved to a yet another abstract class that lacks @execute annotation.

Show
Antti Andreimann added a comment - Thank you. @execute phase= "validate" Seems a bit hackish (it technically still forks a lifecycle which only performs a project validation task), however I think it's a neccessary evil unless most of the code in JettyRunMojo is moved to a yet another abstract class that lacks @execute annotation.

People

  • Assignee:
    Jan Bartel
    Reporter:
    Michael Gorovoy
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: