Maven
  1. Maven
  2. MNG-3401

Plugin parameters must be specified outside an execution block when they are invoked from the command line

    Details

    • Number of attachments :
      1

      Description

      According to Brian E. Fox there is something wrong with the Maven Core which causes the maven-dependency-plugin to fail if it is called by the mvn-eclipse-plugin. I can't tell any specifics since Brian looked into it, and only provided me a workaround. I'm pasting our dialog from the mailing list in here. Any further questions regarding this should be directed to Brian, since I am just a user and do not have the necessary insight.

      ----- snip mailinglist transscript starts here ----

      No, this is a maven core bug and will probably have to be fixed in 2.1, but file an issue anyway.

      ----Original Message----
      From: Michael Heß mhe@ordix.de
      Sent: Thursday, February 14, 2008 12:57 AM
      To: Maven Users List
      Subject: RE: dependency:unpack vs. eclipse:eclipse

      Thanks Brian, for finding this out.
      I have created a workaround as suggested. Only additional thing I had to
      do, was to also bind the resources:resources to process-resources phase,
      because otherwise the filtering occured before the dependency:unpack. It's
      dirty, but at least it works now.

      Have you already taken care of filing a bug? If not, I would take care of
      this. The bug is in the dependency-plugin, right?

      bye, Michael

      Brian E. Fox schrieb:
      > I am able to reproduce this and it's an unfortunate bug in 2.0.x. The only
      > workaround I can suggest is to change the dependency plugin binding to a
      > later phase than is invoked by the eclipse plugin. According to [1] the
      > phase is generate-resources so you can bump it to process-resources.
      >
      > [1]:
      > http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html
      >
      > ----Original Message----
      > From: Michael Heß mhe@ordix.de
      > Sent: Wednesday, February 13, 2008 1:07 AM
      > To: Maven Users List
      > Subject: RE: dependency:unpack vs. eclipse:eclipse
      >
      > Sure,
      >
      > here you go, I hope it somehow survives the transfer to the list. If it's
      > completely garbled I can also send you the file directly as an attachment.
      >
      > Furthermore I'd like to add the error I'm getting when binding the
      > dependendy-plugin unpack goal to a specific phase:
      >
      > ---- ERROR -----
      > [INFO] One or more required plugin parameters are invalid/missing for
      > 'dependency:unpack'
      >
      > [0] Inside the definition for plugin 'maven-dependency-plugin' specify the
      > following:
      >
      > <configuration>
      > ...
      > <artifactItems>VALUE</artifactItems>
      > </configuration>.
      > ---- ERROR -----
      >
      > But as you can see in the pom below, I do have the wanted configuration
      > settings. Thanks for looking into this.
      >
      > bye, Michael
      >
      > --pom starts here--
      >
      > <?xml version="1.0" encoding="UTF-8"?>
      > <project xmlns="http://maven.apache.org/POM/4.0.0"
      > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
      > http://maven.apache.org/maven-v4_0_0.xsd">
      > <parent>
      > <artifactId>abc</artifactId>
      > <groupId>de.customer</groupId>
      > <version>1.0.0-SNAPSHOT</version>
      > </parent>
      > <modelVersion>4.0.0</modelVersion>
      > <groupId>de.customer.abc</groupId>
      > <artifactId>product-config</artifactId>
      > <packaging>jar</packaging>
      > <version>$

      {parent.version}

      </version>
      > <name>product-config</name>
      > <dependencies>
      > <dependency>
      > <groupId>de.customer.abc.common</groupId>
      > <artifactId>abc-basis-config</artifactId>
      > <version>$

      {abc.common.version}</version>
      > <scope>compile</scope>
      > </dependency>
      > </dependencies>
      > <profiles>
      > <profile>
      > <id>local</id>
      > <activation>
      > <property>
      > <name>local</name>
      > </property>
      > </activation>
      > <build />
      > <properties>
      > <maven.test.skip>true</maven.test.skip>
      > <mvn.filter.file>
      > ${basedir}/src/main/filters/local.properties
      > </mvn.filter.file>
      > </properties>
      > </profile>
      > <!--other profiles here as well - intentionally left them out -->
      > </profiles>
      > <build>
      > <filters>
      > <filter>${mvn.filter.file}</filter>
      > </filters>
      > <resources>
      > <resource>
      > <directory>src/main/resources</directory>
      > <filtering>true</filtering>
      > </resource>
      > <resource>
      > <directory>target/work/conf</directory>
      > <!-- copies the contents of "conf" to "target/conf" -->
      > <targetPath>../conf</targetPath>
      > <filtering>true</filtering>
      > </resource>
      > </resources>
      >
      > <plugins>
      > <!-- Java 1.5 -->
      > <plugin>
      > <groupId>org.apache.maven.plugins</groupId>
      > <artifactId>maven-compiler-plugin</artifactId>
      > <configuration>
      > <source>1.5</source>
      > <target>1.5</target>
      > </configuration>
      > </plugin>
      >
      > <plugin>
      > <groupId>org.apache.maven.plugins</groupId>
      > <artifactId>maven-dependency-plugin</artifactId>
      > <version>2.0</version>
      > <inherited>false</inherited>
      > <configuration>
      > <artifactItems>
      > <artifactItem>
      > <groupId>de.customer.abc.common</groupId>
      > <artifactId>abc-basis-config</artifactId>
      > <version>${abc.common.version}

      </version>
      > <type>jar</type>
      > <outputDirectory>
      > $

      {project.build.directory}/work
      > </outputDirectory>
      > </artifactItem>
      > </artifactItems>
      > <excludes>
      > <exclude>META-INF/**</exclude>
      > </excludes>
      > </configuration>
      > <!-- if I put this in, no more eclipse:eclipse
      > <executions>
      > <execution>
      > <id>get-config</id>
      > <phase>generate-resources</phase>
      > <goals>
      > <goal>unpack</goal>
      > </goals>
      > <configuration>
      > <artifactItems>
      > <artifactItem>
      > <groupId>de.customer.abc.common</groupId>
      > <artifactId>abc-basis-config</artifactId>
      > <version>${abc.common.version}</version>
      > <type>jar</type>
      > <outputDirectory>
      > ${project.build.directory}

      /work
      > </outputDirectory>
      > </artifactItem>
      > </artifactItems>
      > <excludes>
      > <exclude>META-INF/**</exclude>
      > </excludes>
      > </configuration>
      > </execution>
      > </executions>
      > -->
      > </plugin>
      > <plugin>
      > <artifactId>maven-assembly-plugin</artifactId>
      > <executions>
      > <execution>
      > <id>conf</id>
      > <phase>package</phase>
      > <goals>
      > <goal>attached</goal>
      > </goals>
      > <configuration>
      > <outputDirectory>
      > $

      {project.build.directory}

      > </outputDirectory>
      > <appendAssemblyId>true</appendAssemblyId>
      > <descriptors>
      > <descriptor>
      > src/main/assembly/conf.xml
      > </descriptor>
      > </descriptors>
      > </configuration>
      > </execution>
      > </executions>
      > </plugin>
      > </plugins>
      > </build>
      > </project>
      >
      >
      >
      > Brian E. Fox schrieb:
      >> The faq entry about the executions/non executions would only apply when
      >> running dependency:unpack directly...it shouldn't have any issues with
      >> eclipse:eclipse. (although I haven't tested it recently).
      >>
      >> Can you paste your pom so I can look at it?
      >>
      >> ----Original Message----
      >> From: Michael Heß mhe@ordix.de
      >> Sent: Tuesday, February 12, 2008 10:34 AM
      >> To: users@maven.apache.org
      >> Subject: dependency:unpack vs. eclipse:eclipse
      >>
      >> Hi list,
      >>
      >> I've been searching and fiddling around all day, with no success so far.
      >> So this is my only hope of finding an answer.
      >>
      >> My basic setup looks like the following:
      >>
      >> I have an artifact which creates a ZIP-assembly. Lets call it
      >> artifact-resources.zip
      >>
      >> Furthermore I have anotherArtifact which depends on
      >> artifact-resources.zip. As the name states, the artifact does not
      >> contain
      >> any sources, but resources. These resources I want to have unpacked and
      >> filtered during anotherArtifacts build. So what I did, was to add a
      >> dependency-plugin-configuration to anotherArtifacts pom.xml, and I bound
      >> it to the generate-resources phase. At that point everything was still
      >> fine. My build went all the way through, the resources got unpacked and
      >> filtered, and were used correctly afterwards as the build lifecycle went
      >> on.
      >>
      >> Then I wanted to use maven-eclipse-plugin on anotherArtifact. At that
      >> point, I ran into the problem, that dependency:unpack fails, because
      >> eclipse:eclipse seems to trigger it in the "CLI" way. Although I do not
      >> really know what it maven internally means, I did as I was told in the
      >> maven-dependency-plugin faq, and removed my execution entries out of the
      >> configuration. This fixed the eclipse:eclipse problem.
      >>
      >> But, now this again leads to the following problems:
      >> Since my maven-dependency-plugin configuration is no longer bound to any
      >> specific phase it should run during process-sources. At least the
      >> plugins
      >> documentation says so. But it does not, I don't know why.
      >>
      >> So, right now my conclusion for today is (and I really do hope someone
      >> can
      >> prove me wrong):
      >>
      >> Either - I can have dependency:unpack attached to a specific phase
      >> OR - I can have eclipse:eclipse working
      >>
      >> As stated before. I spent the whole afternoon trying things out.
      >> Although
      >> I probably learned a lot, I'm desperate for help. I really do not have
      >> any
      >> more ideas what to do.
      >>
      >> Thanks for reading all this, and maybe providing any insight.
      >>
      >> bye, Michael

        Issue Links

          Activity

          Hide
          brianfox brianfox added a comment -

          The problem is that when plugins are invoked from the command line (or bound directly to the default lifecycle), they don't execute with an execution id. This means that the configuration of that plugin must be done outside the <executions> block. This is confusing for the user, but also doesn't allow much flexibility. If you want to support a plugin being run from the command line and bound to the pom, your configuration will be in the default section and thus inherited by all executions. This usually is not what you want.

          Any of these default executions should actually use an execution and we could probably do something simple like use "default" as the execution name.

          Show
          brianfox brianfox added a comment - The problem is that when plugins are invoked from the command line (or bound directly to the default lifecycle), they don't execute with an execution id. This means that the configuration of that plugin must be done outside the <executions> block. This is confusing for the user, but also doesn't allow much flexibility. If you want to support a plugin being run from the command line and bound to the pom, your configuration will be in the default section and thus inherited by all executions. This usually is not what you want. Any of these default executions should actually use an execution and we could probably do something simple like use "default" as the execution name.
          Hide
          Paul Gier added a comment -

          Patch to set the default execution id to "default".

          Show
          Paul Gier added a comment - Patch to set the default execution id to "default".
          Hide
          Benjamin Bentmann added a comment -

          It seems safer to set the execution id in the DefaultLifecycleExecutor via calling the two-arg constructor of MojoExecution. Changing the one-arg constructor would also affect standalone goal executions from the CLI, i.e. <execution>/<configuration> would potentially affect CLI invocations as well.

          Show
          Benjamin Bentmann added a comment - It seems safer to set the execution id in the DefaultLifecycleExecutor via calling the two-arg constructor of MojoExecution . Changing the one-arg constructor would also affect standalone goal executions from the CLI, i.e. <execution>/<configuration> would potentially affect CLI invocations as well.
          Hide
          Paul Gier added a comment -

          Link to related discussion on maven developer list:
          http://www.nabble.com/Default-plugin-execution-id-td20388623.html#a20388623

          Show
          Paul Gier added a comment - Link to related discussion on maven developer list: http://www.nabble.com/Default-plugin-execution-id-td20388623.html#a20388623
          Hide
          John Casey added a comment -

          for mojos invoked directly from the command line, you can supply configuration from the POM using the executionId: 'default-cli' like this:

          <plugin>
            <artifactId>maven-assembly-plugin</artifactId>
            <executions>
              <execution>
                <id>default-cli</id>
                <configuration>
                  <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                    <descriptorRef>project</descriptorRef>
                  </descriptorRefs>
                </configuration>
              </execution>
            </executions>
          </plugin>
          

          This should work in Maven 2.2.0 and 3.x. See IT:

          MavenITmng3401CLIDefaultExecIdTest.java

          Show
          John Casey added a comment - for mojos invoked directly from the command line, you can supply configuration from the POM using the executionId: 'default-cli' like this: <plugin> <artifactId> maven-assembly-plugin </artifactId> <executions> <execution> <id> default-cli </id> <configuration> <descriptorRefs> <descriptorRef> jar-with-dependencies </descriptorRef> <descriptorRef> project </descriptorRef> </descriptorRefs> </configuration> </execution> </executions> </plugin> This should work in Maven 2.2.0 and 3.x. See IT: MavenITmng3401CLIDefaultExecIdTest.java
          Hide
          Benjamin Bentmann added a comment -

          Merged to 3.x in r783520.

          Show
          Benjamin Bentmann added a comment - Merged to 3.x in r783520 .
          Hide
          Mark Howard added a comment -

          The change does help in some situations, but not all. I would much prefer to be able to specify the execution id on the command line.

          For example, I have the surefire plugin setup with 2 executions - 1 bound the the test phase and another bound to the integration test phase.

          I would often want to run mvn surefire:test for the integration test as a standalone command, for example if I've modified some configuration, but don't want to run the full lifecycle. In my case, the pre-integration-test phase takes several seconds, so I don't want to repeat this just to re-run the tests.
          Can't we just have a new syntax along the lines of mvn plugin:goal:execution-id, or mvn plugin:goal -execution=execution-id

          Show
          Mark Howard added a comment - The change does help in some situations, but not all. I would much prefer to be able to specify the execution id on the command line. For example, I have the surefire plugin setup with 2 executions - 1 bound the the test phase and another bound to the integration test phase. I would often want to run mvn surefire:test for the integration test as a standalone command, for example if I've modified some configuration, but don't want to run the full lifecycle. In my case, the pre-integration-test phase takes several seconds, so I don't want to repeat this just to re-run the tests. Can't we just have a new syntax along the lines of mvn plugin:goal:execution-id, or mvn plugin:goal -execution=execution-id
          Hide
          brianfox brianfox added a comment -

          Your best bet is to open a new issue with your improvement idea. The problem as written should be fixed now, but your idea is logical.

          Show
          brianfox brianfox added a comment - Your best bet is to open a new issue with your improvement idea. The problem as written should be fixed now, but your idea is logical.

            People

            • Assignee:
              John Casey
              Reporter:
              Michael Heß
            • Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: