Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      <plugin>
        <artifactId>maven-antrun-plugin</artifactId>
        <executions>
          <execution>
            <phase>install</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <tasks if="jboss.local.repository">
                <property name="version.id" value="${project.version}"/>
                <property name="jboss.local.repository" value="${jboss.local.repository}"/>
                <ant antfile="ant/build-install.xml" target="install"/>
              </tasks>
              <tasks unless="jboss.local.repository">
                <echo message="Cannot install to jboss.local.repository=${jboss.local.repository}"/>
              </tasks>
            </configuration>
          </execution>
        </executions>
      </plugin>
      

      Always executes the last tasks element although 'jboss.local.repository' is set

      [INFO] [antrun:run

      {execution: default}

      ]
      [INFO] Executing tasks
      [echo] Cannot install to jboss.local.repository=/home/tdiesler/svn/jboss.local.repository
      [INFO] Executed tasks

        Issue Links

          Activity

          Hide
          Benjamin Bentmann added a comment -

          If you look at the documentation for the antrun:run goal, you will notice that its parameter tasks is not declared to be of type array/collection. So it's by design that you cannot have multiple <tasks> elements in the same <configuration>. The solution to your use case is to setup multiple <execution> elements, each one having only one <tasks> element.

          Show
          Benjamin Bentmann added a comment - If you look at the documentation for the antrun:run goal, you will notice that its parameter tasks is not declared to be of type array/collection. So it's by design that you cannot have multiple <tasks> elements in the same <configuration> . The solution to your use case is to setup multiple <execution> elements, each one having only one <tasks> element.
          Hide
          Thomas Diesler added a comment -

          Ok, in that case we might want to rename the issue to "Improve configuration error reporting"

          Show
          Thomas Diesler added a comment - Ok, in that case we might want to rename the issue to "Improve configuration error reporting"
          Hide
          Stefan Franke added a comment - - edited

          a workaround is to add ant-contrib to the ant classpath and then use <if> inside of the single target:

          <!-- can contain typos, since I wrote this from scratch... -->
          <configuration>
            <tasks>
              <taskdef name="if" classname="net.sf.antcontrib.logic.IfTask" />
              <if>
                <!-- maybe there is a more elegant way to check a property... -->
                <contains string="${jboss.local.repository}" substring="{jboss.local.repository}">
                  <then>
                    <echo message="Cannot install to jboss.local.repository=${jboss.local.repository}"/>
                </then>
                <else>
                    <property name="version.id" value="${project.version}"/>
                    <property name="jboss.local.repository" value="${jboss.local.repository}"/>
                    <ant antfile="ant/build-install.xml" target="install"/>
                 </else>
                </contains>
              </if>
            </tasks>
          </configuration>
          
          Show
          Stefan Franke added a comment - - edited a workaround is to add ant-contrib to the ant classpath and then use <if> inside of the single target: <!-- can contain typos, since I wrote this from scratch... --> <configuration> <tasks> <taskdef name= " if " classname= "net.sf.antcontrib.logic.IfTask" /> < if > <!-- maybe there is a more elegant way to check a property... --> <contains string= "${jboss.local.repository}" substring= "{jboss.local.repository}" > <then> <echo message= "Cannot install to jboss.local.repository=${jboss.local.repository}" /> </then> < else > <property name= "version.id" value= "${project.version}" /> <property name= "jboss.local.repository" value= "${jboss.local.repository}" /> <ant antfile= "ant/build-install.xml" target= "install" /> </ else > </contains> </ if > </tasks> </configuration>
          Hide
          Kathy Hale added a comment -

          To give you some context, I was trying import 3 targets: start web server, stop web server, and start webserver as debug. They really aren't related to the lifecycle as I see it, but they're still a nice developer tool to have scripted to avoid using services and shell scripts.

          So these seem like my only options unless the plugin was improved/fixed, none of which sound very appealing:

          1. Mash 3 targets into one maven target, and use if/else's to control which is called
          2. Leave these 3 targets in ANT and don't migrate to maven
          3. Bind the targets to arbitrary lifecycle phases (which doesn't really make sense) so I can use <execute>
          Show
          Kathy Hale added a comment - To give you some context, I was trying import 3 targets: start web server, stop web server, and start webserver as debug. They really aren't related to the lifecycle as I see it, but they're still a nice developer tool to have scripted to avoid using services and shell scripts. So these seem like my only options unless the plugin was improved/fixed, none of which sound very appealing: Mash 3 targets into one maven target, and use if/else's to control which is called Leave these 3 targets in ANT and don't migrate to maven Bind the targets to arbitrary lifecycle phases (which doesn't really make sense) so I can use <execute>
          Hide
          Paul Gier added a comment -

          I'm closing this as Won't fix because I believe the logic for deciding which tasks to run doesn't belong in the antrun plugin. If you need multiple tasks, it's probably better to have a separate build.xml file and call that from the antrun using the <ant> task.

          Show
          Paul Gier added a comment - I'm closing this as Won't fix because I believe the logic for deciding which tasks to run doesn't belong in the antrun plugin. If you need multiple tasks, it's probably better to have a separate build.xml file and call that from the antrun using the <ant> task.
          Hide
          Steffl added a comment -

          Pleas re-open this since it is really pain in the a*** to do all this workarround just to decide which target should be executed. It costs me 3 hours until now! And what I got is unreadable, crazy configurations. And I'am not the only one. It could be so easy:

          <target name="targetA" if="doTargetA">
          </target>

          <target name="targetB" if="doTargetB">
          </target>

          You mentioned, the reason why you won't fix is because you "believe the logic for deciding which tasks to run doesn't belong in the antrun plugin". OK, but there is already logic support for the "if" and "unless" attributes on a single <target/> element. In my opinion, this is not consequently enough. Either you drop support for these attributes completely or you support multimple target elements (I would prefer).

          Please re-think. Thanks a lot.

          Show
          Steffl added a comment - Pleas re-open this since it is really pain in the a*** to do all this workarround just to decide which target should be executed. It costs me 3 hours until now! And what I got is unreadable, crazy configurations. And I'am not the only one. It could be so easy: <target name="targetA" if="doTargetA"> </target> <target name="targetB" if="doTargetB"> </target> You mentioned, the reason why you won't fix is because you "believe the logic for deciding which tasks to run doesn't belong in the antrun plugin". OK, but there is already logic support for the "if" and "unless" attributes on a single <target/> element. In my opinion, this is not consequently enough. Either you drop support for these attributes completely or you support multimple target elements (I would prefer). Please re-think. Thanks a lot.
          Hide
          Paul Gier added a comment -

          Can you use multiple antrun executions? I would think this will accomplish the same thing.
          If that doesn't work for you, the best thing is probably to create a new jira issue and attach a patch.

          Show
          Paul Gier added a comment - Can you use multiple antrun executions? I would think this will accomplish the same thing. If that doesn't work for you, the best thing is probably to create a new jira issue and attach a patch.

            People

            • Assignee:
              Paul Gier
              Reporter:
              Thomas Diesler
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: