After the extra scn co's, the revision is 355792. I missed changing that before saving.

which ant release are you using ? 1.6.5 ?

1.6.2. Site says 1.5 or higher. Prob time to upgrade anyways...

Jeff, any update on this? I'm afraid we can't reproduce it (luckily ).

I encountered it several times on windows. This is certainly specific to this OS.
I think that it is due to the fact that in some plugins' tests we call the clean goal after the test and not before.
If windows is a little bit slow, an handle isn't remove and the delete step fails.

After Arnaud gave me a b3 snapshot, and posts them, I stopped bootstrapping. So nothing further since.

Does Arnaud's answer (reproduced) give what is needed?

Do you want me to try again?

Thanks Jeff, it's not necessary that you dig any further.
I didn't know that Arnaud could reproduce the problem, so let's leave it up to him (boy, am I glad to run Linux, the bootstrap is long enough without occasional fails...).

I checked that to test all plugins we called always the clean goal before the test and never after (to avoid to delete a locked file or directory after a test -> Windows OS only).
I tested several times and I didn't reproduce it.

I reproduced it again

Not sure when we'll fix it

It can be related to this note given in the javac ant task :

Windows Note:When the modern compiler is used in unforked mode on Windows, it locks up the files present in the classpath of the <javac> task, and does not release them. The side effect of this is that you will not be able to delete or move those files later on in the build. The workaround is to fork when invoking the compiler.

http://ant.apache.org/manual/CoreTasks/javac.html

A workarround can be to set maven.compile.fork=true
Since I applied it locally I didn't yet reproduce it.

Can be related to some InputStream not properly closed in our code ??

I didn't reproduce it for several months. I think we'll close it