I've run into a similar situation and I'll explain how I resolved this
problem. There are two way's that I've solved this, both of which are
used to inform the reactor of the inter-module dependency:
1) Simply add SomeModuleWAR to your dependency list. This is generally
a good idea to help the reactor resolve the dependency order (I'm
guessing it's worked so far since you've declared your modules in the
order you expect) as well as make the artifact available in the reactor
for the release. This has an awkward side affect of listing the
dependency twice, once in the unpack declaration and once in the
dependency section.
2) Use dependency:unpack-dependencies and declare SomeModuleWAR in your
dependency list. If you have more than just this SomeModuleWAR as a
dependency you're probably going to want to use the includeArtifactIds
configuration. This ensures that you only declare the full dependency
once and don't have to worry about versions being out of line.
My understanding is that by using the dependency:unpack this is not
participating in dependency resolution in the reactor, only checking if
the artifact is in your local repo.
Personally I prefer to use the second approach since I don't like the
redundant declaration of the full dependency information.
Hope that helps.
Jamie.
On Wed, 2008-12-17 at 23:15 +0100, da...@davidkarlsen.com wrote:
> Hi - we have a classical jee setup with jar/war/ear and a ws-client
> dep: ear <- war <- jar
>
> the ws-client is part of the same multimodule as the others - same parent
> and all.
>
> The ws-client has:
>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
> <phase>generate-sources</phase>
> <goals>
> <goal>unpack</goal>
> </goals>
> <configuration>
> <artifactItems>
> <artifactItem>
> <groupId>${project.groupId}</groupId>
> <artifactId>SomeModuleWAR</artifactId>
> <type>war</type>
> <version>${project.version}</version>
> </artifactItem>
> </artifactItems>
> <includes>**/*.wsdl</includes>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
>
> inside it (to unpack wsdls and generate clients).
>
> I fI do release:prepare -DdryRun=true on the whole multimodule it's OK.
> It fails when doing release:prepare for real - because the SomeModuleWAR
> is not available in local repo because the default prepare goals are:
> clean verify :
> http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#preparationGoals
>
> now - why does this fail? does the dependency plugin check for the
> artifact before it'sr eally executed? because clean verify should not
> trigger generate-sources - where the dep. is needed:
> http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html
>
> Anybody else hit this?
>
> --
> David J. M. Karlsen - +47 90 68 22 43
> http://www.davidkarlsen.com
> http://mp3.davidkarlsen.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is authorized. Any
liability arising from any party acting, or refraining from acting, on any
information contained in this e-mail is hereby excluded. If you are not the
intended recipient, please notify the sender immediately, destroy the original
transmission and its attachments and do not disclose the contents to any other
person, use it for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or
its affiliated entities.
