Maven 1

Bootstrap failure: Unable to delete directory ...

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.1-beta-3
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Win XP, svn Checked out revision 355781.
  • Number of attachments :
    1

Description

bootstrap consistently fails. Attached is log for my last run.

This is an interesting line from it:
[exec] Caused by: Unable to delete directory C:\devroot\reference\maven\maven-1\plugins\trunk\genapp\src\plugin-test\nonStandardDirsTest\target

I completely deleted the svn dirs and got latest. The error above prior was this:
[exec] Root cause
[exec] Unable to delete directory C:\devroot\reference\maven\maven-1\plugins\trunk\genapp\src\plugin-test\mavenHomeLocalTemplateTest\target

And the run that failed before that one did not have an "unable to delete dir". (I did about 6 or so bootstraps today, trying to get it to work)

They are on different plugins, such as Javadoc, Test Genapp. I have 3 of my last logs, and a couple of them are the test genapp (not the middle run of the 3).

I hope something helps here, and this isn't some silly chase. Thanks again for looking into it.
I tried to determine some environment thing for me.
Oh, typing of environment, I am using JDK 1.5. Is that OK, or perhaps the prob?

Issue Links

depends upon

Bug - A problem which impairs or prevents the functions of the product. MAVEN-1761 org.apache.maven.MavenUtils.loadProperties(..) does not close the FileInputStream (relying upon finalization)

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jeff Jensen added a comment -

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

Show
Jeff Jensen added a comment - After the extra scn co's, the revision is 355792. I missed changing that before saving.
Hide
Permalink
Arnaud Heritier added a comment -

which ant release are you using ? 1.6.5 ?

Show
Arnaud Heritier added a comment - which ant release are you using ? 1.6.5 ?
Hide
Permalink
Jeff Jensen added a comment -

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

Show
Jeff Jensen added a comment - 1.6.2. Site says 1.5 or higher. Prob time to upgrade anyways...
Hide
Permalink
Lukas Theussl added a comment -

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

Show
Lukas Theussl added a comment - Jeff, any update on this? I'm afraid we can't reproduce it (luckily ).
Hide
Permalink
Arnaud Heritier added a comment -

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.

Show
Arnaud Heritier added a comment - 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.
Hide
Permalink
Jeff Jensen added a comment -

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?

Show
Jeff Jensen added a comment - 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?
Hide
Permalink
Lukas Theussl added a comment -

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...).

Show
Lukas Theussl added a comment - 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...).
Hide
Permalink
Arnaud Heritier added a comment -

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.

Show
Arnaud Heritier added a comment - 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.
Hide
Permalink
Arnaud Heritier added a comment -

I reproduced it again

Show
Arnaud Heritier added a comment - I reproduced it again
Hide
Permalink
Arnaud Heritier added a comment -

Not sure when we'll fix it

Show
Arnaud Heritier added a comment - Not sure when we'll fix it
Hide
Permalink
Arnaud Heritier added a comment -

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.

Show
Arnaud Heritier added a comment - 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.
Hide
Permalink
Arnaud Heritier added a comment -

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

Show
Arnaud Heritier added a comment - Can be related to some InputStream not properly closed in our code ??
Hide
Permalink
Arnaud Heritier added a comment -

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

Show
Arnaud Heritier added a comment - I didn't reproduce it for several months. I think we'll close it

People

  • Assignee:
    Unassigned
    Reporter:
    Jeff Jensen
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: