You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Steinar Bang <sb...@dod.no> on 2008/05/03 23:19:50 UTC
Flaky antrun:run behaviour with unzip and zip
Platform: Ubuntu 8.04, Intel Pentium M,
maven 2.0.8,
maven-antrun-plugin 1.1
I have a <plugin> config to fix the version numbers of OSGi bundles for
snapshot version. Eg. change "1.1.0-SNAPSHOT" to "1.1.0.SNAPSHOT". The
full <plugin> config is shown at the end of this message.
It works by:
- unzipping the bundle jar
- fixing the META-INF/MANIFEST.MF
- zipping up the jar again
This is done in the verify phase, so that it should be performed after
the jar:jar goal, which is done in the package phase, and before the
install phase.
The problem is that the <zip> isn't always executed when running the
bundle projects as part of a multi-project. And when the <zip> target
isn't run, the bundle doesn't have the correct version number (the
bundles aren't proper bundles. They are meant as scaffolding for
thirdparty libraries. That's why only the META-INF directory is
packaged up).
Which projects in the multi-project that fails, differs from run to run.
I build with "mvn clean install.
Does anyone know why this might fail? Is it some sort of timing issue?
When it works it looks like this
[unzip] Expanding: /home/sb/p4/depot/myproj/MAIN/com.mycompany.thirdparty.commons.codec/target/com.mycompany.thirdparty.commons.codec_1.1.0-SNAPSHOT.jar into /home/sb/p4/depot/myproj/MAIN/com.mycompany.thirdparty.commons.codec/target
[zip] Building zip: /home/sb/p4/depot/myproj/MAIN/com.mycompany.thirdparty.commons.codec/target/com.mycompany.thirdparty.commons.codec_1.1.0-SNAPSHOT.jar
When it fails, there's just the [unzip] line. And sometimes I see
something like this:
[unzip] Expanding: /home/sb/p4/depot/myproj/MAIN/com.mycompany.thirdparty.xercesimpl/target/com.mycompany.thirdparty.xercesimpl_1.1.0-SNAPSHOT.jar into /home/sb/p4/depot/myproj/MAIN/com.mycompany.thirdparty.xercesimpl/target
[zip] Warning: META-INF/maven modified in the future.
[zip] Warning: META-INF/maven/com.mycompany.thirdparty.xercesimpl modified in the future.
[zip] Warning: META-INF/maven/com.mycompany.thirdparty.xercesimpl/com.mycompany.thirdparty.xercesimpl modified in the future.
(no NFS mounted drives to give modify time strangeness. Everything is
taking place on the same ext3 filesystem, with a single-core Pentium-M)
I've followed this pattern in other places, to fix things in zip and jar
files, but I have never seen strangeness like this.
The full <plugin> config looks like this:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>fix-snapshot-bundle-version</id>
<goals>
<goal>run</goal>
</goals>
<phase>verify</phase>
<configuration>
<tasks>
<unzip src="${project.build.directory}/${artifactId}_${version}.jar" dest="${project.build.directory}" />
<replace file="${project.build.directory}/META-INF/MANIFEST.MF" token="-SNAPSHOT" value=".SNAPSHOT" />
<zip destfile="${project.build.directory}/${artifactId}_${version}.jar">
<fileset dir="${project.build.directory}" includes="META-INF/**" />
</zip>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Flaky antrun:run behaviour with unzip and zip
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Jason van Zyl <ja...@maven.org>:
> Just trying to determine if it's a Ant problem, or an Ant inside Maven
> problem.
If the behaviour wasn't so unpredictable, I would have tried to create a
simple test case to make it appear, and then reported the issue to
antrun, and if it was revealed to be an ant problem, let it trickle down
to ant.
But the way it is, I don't know how to report it.
I _suspect_ it's an issue with the ant zip target, when the zip target
file already exists. But I don't know how to reproduce it in a
predictable manner.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Flaky antrun:run behaviour with unzip and zip
Posted by Jason van Zyl <ja...@maven.org>.
Just trying to determine if it's a Ant problem, or an Ant inside Maven
problem.
On 4-May-08, at 11:08 AM, Steinar Bang wrote:
>>>>>> Jason van Zyl <ja...@maven.org>:
>
>> Does it work in a simple ant script.
>
> You mean to just do:
> <unzip>
> <replace>
> <zip>
> ?
>
> I don't know. I haven't tried (I don't know ant very well, outside of
> googling for ant tasks, to be put inside a <tasks> configuration
> element
> of antrun executions...).
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Flaky antrun:run behaviour with unzip and zip
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Jason van Zyl <ja...@maven.org>:
> Does it work in a simple ant script.
You mean to just do:
<unzip>
<replace>
<zip>
?
I don't know. I haven't tried (I don't know ant very well, outside of
googling for ant tasks, to be put inside a <tasks> configuration element
of antrun executions...).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Flaky antrun:run behaviour with unzip and zip
Posted by Jason van Zyl <ja...@maven.org>.
Does it work in a simple ant script.
On 4-May-08, at 9:47 AM, Steinar Bang wrote:
>>>>>> Steinar Bang <sb...@dod.no>:
>
> [snip! Things that didn't work]
>
> I added a <delete> of the original jar file, before the zip task, and
> then it worked. Ie.
> <unzip>
> <replace>
> <delete>
> <zip>
>
> So it was probably something about zip and overwriting of the existing
> file that caused the flaky behaviour. Why it sometimes worked, and
> why
> a <sleep> worked for some projects, is still a mystery.
>
> The entire <plugin> config for each project, looks like this now:
> <plugin>
> <artifactId>maven-antrun-plugin</artifactId>
> <executions>
> <execution>
> <id>fix-snapshot-bundle-version</id>
> <goals>
> <goal>run</goal>
> </goals>
> <phase>verify</phase>
> <configuration>
> <tasks>
> <unzip src="${project.build.directory}/${artifactId}_$
> {version}.jar" dest="${project.build.directory}" />
> <replace file="${project.build.directory}/META-INF/
> MANIFEST.MF" token="-SNAPSHOT" value=".SNAPSHOT" />
> <delete file="${project.build.directory}/${artifactId}_$
> {version}.jar" />
> <zip destfile="${project.build.directory}/${artifactId}_$
> {version}.jar">
> <fileset dir="${project.build.directory}" includes="META-INF/
> **" />
> </zip>
> </tasks>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A language that doesn’t affect the way you think about programming is
not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Flaky antrun:run behaviour with unzip and zip
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
[snip! Things that didn't work]
I added a <delete> of the original jar file, before the zip task, and
then it worked. Ie.
<unzip>
<replace>
<delete>
<zip>
So it was probably something about zip and overwriting of the existing
file that caused the flaky behaviour. Why it sometimes worked, and why
a <sleep> worked for some projects, is still a mystery.
The entire <plugin> config for each project, looks like this now:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>fix-snapshot-bundle-version</id>
<goals>
<goal>run</goal>
</goals>
<phase>verify</phase>
<configuration>
<tasks>
<unzip src="${project.build.directory}/${artifactId}_${version}.jar" dest="${project.build.directory}" />
<replace file="${project.build.directory}/META-INF/MANIFEST.MF" token="-SNAPSHOT" value=".SNAPSHOT" />
<delete file="${project.build.directory}/${artifactId}_${version}.jar" />
<zip destfile="${project.build.directory}/${artifactId}_${version}.jar">
<fileset dir="${project.build.directory}" includes="META-INF/**" />
</zip>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Flaky antrun:run behaviour with unzip and zip
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
> Maybe timing related...?
> As an experiment, inserting a
> <sleep second="10" />
> between the unzip and the <replace> worked for all of the projects
> except for the two latest projects (which consistently failed).
> But
> 1. I still don't know why the two last projects consistently fail
> 2. adding an extra 10s to each project slows down the build
> And introducing a wait to make things work is always a hack.
> I tried doing this instead of the sleep:
> <waitfor>
> <available file="${project.build.directory}/META-INF/MANIFEST.MF" />
> </waitfor>
> But that didn't work. It didn't stop and wait either.
I tried something more:
- splitting up the unzip from the replace and zip tasks in two separate
executions in the verify phase, that didn't help
- running the unzip execution in the integration-test phase. That
didn't help either, so that shoots holes in the timing theory
Another possible culprit is the use of ${project.build.directory}. Is
that always right when running a multi-project? (it seems to be, from
the [unzip] output, and for the [zip] output where we get it. But there
may be issues there...?)
I tried replacing it with ${basedir}/target, but that didn't make any
difference.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Flaky antrun:run behaviour with unzip and zip
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
> I have a <plugin> config to fix the version numbers of OSGi bundles for
> snapshot version. Eg. change "1.1.0-SNAPSHOT" to "1.1.0.SNAPSHOT". The
> full <plugin> config is shown at the end of this message.
> It works by:
> - unzipping the bundle jar
> - fixing the META-INF/MANIFEST.MF
> - zipping up the jar again
[snip!]
> The problem is that the <zip> isn't always executed when running the
> bundle projects as part of a multi-project. And when the <zip> target
> isn't run, the bundle doesn't have the correct version number (the
> bundles aren't proper bundles. They are meant as scaffolding for
> thirdparty libraries. That's why only the META-INF directory is
> packaged up).
> Which projects in the multi-project that fails, differs from run to run.
> I build with "mvn clean install.
> Does anyone know why this might fail? Is it some sort of timing issue?
Maybe timing related...?
As an experiment, inserting a
<sleep second="10" />
between the unzip and the <replace> worked for all of the projects
except for the two latest projects (which consistently failed).
But
1. I still don't know why the two last projects consistently fail
2. adding an extra 10s to each project slows down the build
And introducing a wait to make things work is always a hack.
I tried doing this instead of the sleep:
<waitfor>
<available file="${project.build.directory}/META-INF/MANIFEST.MF" />
</waitfor>
But that didn't work. It didn't stop and wait either.
But why should something like this be timing related? Doesn't all tasks
inside a target execute sequentially, in the same thread?
What happens when [zip] is not listed in the maven output? Doesn't zip
run, because there are no files to zip up? Is there a way to make it
more verbose?
Thanx!
- Steinar
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org