[
http://jira.codehaus.org/browse/MNG-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3401:
---------------------------
Summary: Plugin parameters must be specified outside an execution block
when they are invoked from the command line (was: Maven Dependency Plugin vs
Eclipse Plugin Errors caused by MVN Core)
> Plugin parameters must be specified outside an execution block when they are
> invoked from the command line
> ----------------------------------------------------------------------------------------------------------
>
> Key: MNG-3401
> URL: http://jira.codehaus.org/browse/MNG-3401
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Affects Versions: 2.0.8
> Reporter: Michael Heß
>
> 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ß [mailto:[EMAIL PROTECTED]
> 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ß [mailto:[EMAIL PROTECTED]
> > 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ß [mailto:[EMAIL PROTECTED]
> >> Sent: Tuesday, February 12, 2008 10:34 AM
> >> To: [EMAIL PROTECTED]
> >> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
