Jetty
  1. Jetty
  2. JETTY-1405

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. pom.xml
        2 kB
        Antti Andreimann

        Activity

        Hide
        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.
        Hide
        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 ---
        Hide
        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; }
        Hide
        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
        Hide
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: