The solution outlined below is the recommended way to handle this.
Copy/unpack was meant to handle external artifacts.
--Brian (mobile)
On Dec 18, 2008, at 4:28 PM, Jamie Whitehouse <[email protected]
> wrote:
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, [email protected] 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: [email protected]
For additional commands, e-mail: [email protected]
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
----------------------------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
