Luciano Resende wrote:
On Sun, May 23, 2010 at 1:52 PM, Raymond Feng <[email protected]> wrote:
I tried to run the build on Windows and everything works.
For the Mac OS issue, I ran a build from the root first and I don't see
anything copied into binaries/target. Then I tried to run the build again
from binaries/ and binaries/bundle. None of them helped.
I saw the message:
[INFO] Copying files to
/Users/rfeng/Projects/tuscany/sca-java-1.x/tags/travelsample-1.0-RC1/binaries/target/.
But there is nothing under binaries (not even the target folder).
I found out that the "binaries/target" folder is not created by maven during
the build on Mac. If I create it manually, then the build successfully
copies all the files into binaries/target. So a quick workaround is to
create binaries/target as part of the build.
Thanks,
Raymond
I tried building from the tag, and I'm experiencing the same behavior
(in the same Mac OS environment). I have played with some of the
assembly files trying to fix but didn't seem to find any obvious
solution...
This might a bit tricky for me to debug as I don't have access to Mac OSX.
I'd be interested to know if the problem is specific to Mac OSX or also
affect other Linux OSs. Could anyone try this?
I'm also interested to know which version of maven is producing the
failure. I'm using maven 2.0.10.
The output directory is set to "../target" in the pom.xml for binaries/bundle
using the <outputDirectory> element of the maven-assembly-plugin configuration.
There's similar code in the pom.xml files for binaries/jaxws, binaries/ode
and binaries/openejb. For some reason on Mac OSX the maven assembly plugin
isn't creating this "../target" directory.
Some suggestions:
1. In the pom.xml for binaries/bundle, force the creation of the "../target"
directory by replacing the current maven-antrun-plugin <plugin> section
by the following:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>package-mkdir</id>
<phase>package</phase>
<configuration>
<tasks>
<mkdir dir="../target"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
<execution>
<id>install-delete</id>
<phase>install</phase>
<configuration>
<tasks>
<delete dir="../target/domainconfig/META-INF"
includeemptydirs="true"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
This works for me on Windows and forces explicit creation of the directory.
The build output is as follows:
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Apache Tuscany SCA Tours Binaries Bundle
[INFO] Apache Tuscany SCA Tours Binaries JAX-WS Dependencies for JDK 5
[INFO] Apache Tuscany SCA Tours Binaries ODE Database
[INFO] Apache Tuscany SCA Tours Binaries OpenEJB Dependencies
[INFO] Apache Tuscany SCA Tours Binaries
[INFO]
------------------------------------------------------------------------
[INFO] Building Apache Tuscany SCA Tours Binaries Bundle
[INFO] task-segment: [install]
[INFO]
------------------------------------------------------------------------
[INFO] [site:attach-descriptor]
[INFO] [antrun:run {execution: package-mkdir}]
[INFO] Executing tasks
[mkdir] Created dir: E:\td\book\rel\travelsample\binaries\target
[INFO] Executed tasks
[INFO] [assembly:single {execution: distribution-package}]
[INFO] Reading assembly descriptor: ../src/main/assembly/bin.xml
[INFO] Processing DependencySet (output=util)
...etc.
I have placed a version of this file in my people.apache.org/~nash/tuscany/
directory as travelsample-binaries-bundle-pom-patch.xml. Could someone try
replacing the binaries/bundle pom.xml from the distribution by this version
before running the top-level build of travelsample on Mac OSX to see if this
fixes the problem?
2. Instead of using <outputDirectory>../target</outputDirectory> in the
maven-assembly-plugin configurations, use <directory>../target</directory>
within the <profile> <build> configurations in all of the pom.xml files
for the "binaries" subdirectories. I don't like this as much as option 1
because it's a more extensive change and it also has the unfortunate
side effect of polluting the binaries/target directory by creating an
empty archive-tmp directory there.
Simon
