>>>>> Steinar Bang <[EMAIL PROTECTED]>:
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
