You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/12/09 11:38:30 UTC

ADS Code analysis

http://insite.metrixware.com/14,ApacheDirectoryServer,Software_Quality_SQALE_Open_Source_Java_LDAP.html

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Re: Latest trunk test failures on Windows XP

Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On 10 déc. 2010, at 17:12, feezelr@gdls.com wrote:

> 
> Pierre-Arnaud Marcelot <pa...@gmail.com> wrote on 12/10/2010 05:48:48 AM:
> 
> > Hi again Richard, 
> > 
> > I added 200 ms more before checking the values of the test. 
> > 
> > Looks like Thread.sleep is not very reliable (especially on Windows). 
> 
> Timing on XP seems to have a resolution of 16.7 msec. 
> 
> > You should be able to build ApacheDS on Windows now. ;) 
> 
> I just completed an "svn up", "mvn install -DskipTests" and "mvn test -Dintegration" successfully. 
> 
> Looks good from here!

Great!

Thanks for the confirmation. ;)

> > Thanks, 
> > Pierre-Arnaud 
> 
> 
> . This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.


Re: Latest trunk test failures on Windows XP

Posted by fe...@gdls.com.
Pierre-Arnaud Marcelot <pa...@gmail.com> wrote on 12/10/2010 05:48:48 AM:

> Hi again Richard,
> 
> I added 200 ms more before checking the values of the test.
> 
> Looks like Thread.sleep is not very reliable (especially on Windows).

Timing on XP seems to have a resolution of 16.7 msec.

> You should be able to build ApacheDS on Windows now. ;)

I just completed an "svn up", "mvn install -DskipTests" and "mvn test 
-Dintegration" successfully.

Looks good from here!

> Thanks,
> Pierre-Arnaud


.


This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information.  No one else may read, print, store, copy, forward or act in reliance on it or its attachments.  If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.


Re: Latest trunk test failures on Windows XP

Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi again Richard,

I added 200 ms more before checking the values of the test.

Looks like Thread.sleep is not very reliable (especially on Windows).

You should be able to build ApacheDS on Windows now. ;)

Thanks,
Pierre-Arnaud


On 9 déc. 2010, at 20:28, feezelr@gdls.com wrote:

> 
> I've just checked out trunk and I'm getting a couple of test failures. 
> 
> First ReplayCacheImplTest was failing until I changed line 100 to "Thread.sleep( 1200 );" 
> 
> Second org.apache.directory.server.config.LdapServerConfigReaderTest fails with an error trying to delete the contents of the work directory: 
> 
> ------------------------------------------------------------------------------- 
> Test set: org.apache.directory.server.config.LdapServerConfigReaderTest 
> ------------------------------------------------------------------------------- 
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.532 sec <<< FAILURE! 
> org.apache.directory.server.config.LdapServerConfigReaderTest  Time elapsed: 0 sec  <<< ERROR! 
> java.io.IOException: Unable to delete file: C:\DOCUME~1\feezelr\LOCALS~1\Temp\server-work\configReader\config.ldif 
>         at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1390) 
>         at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1044) 
>         at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:977) 
>         at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1381) 
>         at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1044) 
>         at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:977) 
>         at org.apache.directory.server.config.LdapServerConfigReaderTest.readConfig(LdapServerConfigReaderTest.java:66) 
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
>         at java.lang.reflect.Method.invoke(Method.java:597) 
>         at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) 
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) 
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) 
>         at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) 
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:236) 
>         at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) 
>         at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120) 
>         at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103) 
>         at org.apache.maven.surefire.Surefire.run(Surefire.java:169) 
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
>         at java.lang.reflect.Method.invoke(Method.java:597) 
>         at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) 
>         at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) 
> 
> 
> This looks to me like another instance of an attempt to delete a file while it is still open.  This type of problem seems to be unique to the Windows environment.  In this case, however, it's not obvious to my why the file would be in use.  Is this possibly a consequence of trying to run tests concurrently? 
> 
> 
> . This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.


Re: Latest trunk test failures on Windows XP

Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Richard,

The issue on the LdapServerConfigReaderTest has been fixed.

It was a mistake on my side. I forgot to close an LdifReader instance opened on the 'config.ldif' file in the ConfigWriterTest class (which is executed just before the LdapServerConfigReaderTest class).

Thanks for finding this one and keeping an eye on the build on Windows (something we should probably do more often ourselves too).

Now looking at the ReplayCache issue.

Regards,
Pierre-Arnaud


On 9 déc. 2010, at 20:28, feezelr@gdls.com wrote:

> 
> I've just checked out trunk and I'm getting a couple of test failures. 
> 
> First ReplayCacheImplTest was failing until I changed line 100 to "Thread.sleep( 1200 );" 
> 
> Second org.apache.directory.server.config.LdapServerConfigReaderTest fails with an error trying to delete the contents of the work directory: 
> 
> ------------------------------------------------------------------------------- 
> Test set: org.apache.directory.server.config.LdapServerConfigReaderTest 
> ------------------------------------------------------------------------------- 
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.532 sec <<< FAILURE! 
> org.apache.directory.server.config.LdapServerConfigReaderTest  Time elapsed: 0 sec  <<< ERROR! 
> java.io.IOException: Unable to delete file: C:\DOCUME~1\feezelr\LOCALS~1\Temp\server-work\configReader\config.ldif 
>         at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1390) 
>         at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1044) 
>         at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:977) 
>         at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1381) 
>         at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1044) 
>         at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:977) 
>         at org.apache.directory.server.config.LdapServerConfigReaderTest.readConfig(LdapServerConfigReaderTest.java:66) 
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
>         at java.lang.reflect.Method.invoke(Method.java:597) 
>         at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) 
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) 
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) 
>         at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) 
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:236) 
>         at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) 
>         at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120) 
>         at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103) 
>         at org.apache.maven.surefire.Surefire.run(Surefire.java:169) 
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
>         at java.lang.reflect.Method.invoke(Method.java:597) 
>         at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) 
>         at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) 
> 
> 
> This looks to me like another instance of an attempt to delete a file while it is still open.  This type of problem seems to be unique to the Windows environment.  In this case, however, it's not obvious to my why the file would be in use.  Is this possibly a consequence of trying to run tests concurrently? 
> 
> 
> . This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.


Re: Latest trunk test failures on Windows XP

Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Richard, Antoine,

I will look into it on my Windows VM too.

Regards,
Pierre-Arnaud

On 9 déc. 2010, at 21:33, Antoine Levy-Lambert wrote:

> On 12/9/2010 2:33 PM, Emmanuel Lecharny wrote:
>> On 12/9/10 8:28 PM, feezelr@gdls.com wrote:
>>> I've just checked out trunk and I'm getting a couple of test failures.
>>> 
>>> First ReplayCacheImplTest was failing until I changed line 100 to "Thread.
>>> sleep( 1200 );"
>>> Second org.apache.directory.server.config.LdapServerConfigReaderTest fails
>>> with an error trying to delete the contents of the work directory:
>>> 
>>> 
>>> 
>>> This looks to me like another instance of an attempt to delete a file
>>> while it is still open.  This type of problem seems to be unique to the
>>> Windows environment.  In this case, however, it's not obvious to my why
>>> the file would be in use.  Is this possibly a consequence of trying to run
>>> tests concurrently?
>> Probably. It's a serious issue we already faced lately and we have fixed some of them, but it seems there are some remaining failures.
>> 
>> Sadly, none of us have a windows env to debug the code...
>> 
>> 
> I have a Windows env. I will try that.
> 
> Antoine
> 


Re: Latest trunk test failures on Windows XP

Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Emmanuel,

On 10 déc. 2010, at 01:32, Emmanuel Lecharny wrote:

> Hi Antoine,
> 
> I have merged your branch into trunk, except the config.ldif file, because it's way too complex to merge it (there are hundreds of line, and for some unknown reason, svn diff sees both files as completely different.

Hum, probably my fault, as I made some changes to the config.ldif file in the branch I merged recently.

Sorry about it...

Regards,
Pierre-Arnaud


> Can you tell me what entries you have modified ? you should be able to easily do that by doing a diff on your disk.
> 
> Many thanks !
> 
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
> 


Re: Latest trunk test failures on Windows XP

Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Emmanuel,

I added these entries

dn: 
ou=authenticators,ads-interceptorId=authenticationInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=config
ou: authenticators
objectclass: organizationalUnit
objectclass: top

dn: 
ads-authenticatorid=anonymousauthenticator,ou=authenticators,ads-interceptorId=authenticationInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=config
ads-authenticatorid: anonymousauthenticator
objectclass: top
objectclass: ads-base
objectClass: ads-authenticator
objectClass: ads-anonymousAuthenticator

dn: 
ads-authenticatorid=simpleauthenticator,ou=authenticators,ads-interceptorId=authenticationInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=config
ads-authenticatorid: simpleauthenticator
objectclass: top
objectclass: ads-base
objectClass: ads-authenticator
objectClass: ads-simpleAuthenticator

dn: 
ads-authenticatorid=strongauthenticator,ou=authenticators,ads-interceptorId=authenticationInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=config
ads-authenticatorid: strongauthenticator
objectclass: top
objectclass: ads-base
objectClass: ads-authenticator
objectClass: ads-strongAuthenticator

my vision is to configure all authenticators explicitly in the DIT.
What the above implies is that it is possible to have any combination of 
authenticators.

Regards,

Antoine

On 12/9/2010 7:32 PM, Emmanuel Lecharny wrote:
> Hi Antoine,
>
> I have merged your branch into trunk, except the config.ldif file, 
> because it's way too complex to merge it (there are hundreds of line, 
> and for some unknown reason, svn diff sees both files as completely 
> different.
>
> Can you tell me what entries you have modified ? you should be able to 
> easily do that by doing a diff on your disk.
>
> Many thanks !
>
>


Re: Latest trunk test failures on Windows XP

Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Antoine,

I have merged your branch into trunk, except the config.ldif file, 
because it's way too complex to merge it (there are hundreds of line, 
and for some unknown reason, svn diff sees both files as completely 
different.

Can you tell me what entries you have modified ? you should be able to 
easily do that by doing a diff on your disk.

Many thanks !


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Re: Latest trunk test failures on Windows XP

Posted by Antoine Levy-Lambert <an...@gmx.de>.
On 12/9/2010 2:33 PM, Emmanuel Lecharny wrote:
> On 12/9/10 8:28 PM, feezelr@gdls.com wrote:
>> I've just checked out trunk and I'm getting a couple of test failures.
>>
>> First ReplayCacheImplTest was failing until I changed line 100 to 
>> "Thread.
>> sleep( 1200 );"
>> Second org.apache.directory.server.config.LdapServerConfigReaderTest 
>> fails
>> with an error trying to delete the contents of the work directory:
>>
>>
>>
>> This looks to me like another instance of an attempt to delete a file
>> while it is still open.  This type of problem seems to be unique to the
>> Windows environment.  In this case, however, it's not obvious to my why
>> the file would be in use.  Is this possibly a consequence of trying 
>> to run
>> tests concurrently?
> Probably. It's a serious issue we already faced lately and we have 
> fixed some of them, but it seems there are some remaining failures.
>
> Sadly, none of us have a windows env to debug the code...
>
>
I have a Windows env. I will try that.

Antoine


Re: Latest trunk test failures on Windows XP

Posted by Emmanuel Lecharny <el...@gmail.com>.
On 12/9/10 8:28 PM, feezelr@gdls.com wrote:
> I've just checked out trunk and I'm getting a couple of test failures.
>
> First ReplayCacheImplTest was failing until I changed line 100 to "Thread.
> sleep( 1200 );"
> Second org.apache.directory.server.config.LdapServerConfigReaderTest fails
> with an error trying to delete the contents of the work directory:
>
> -------------------------------------------------------------------------------
> Test set: org.apache.directory.server.config.LdapServerConfigReaderTest
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.532 sec
> <<<  FAILURE!
> org.apache.directory.server.config.LdapServerConfigReaderTest  Time
> elapsed: 0 sec<<<  ERROR!
> java.io.IOException: Unable to delete file: C:\DOCUME~1\feezelr\LOCALS~1\
> Temp\server-work\configReader\config.ldif
>          at
> org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1390)
>          at
> org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1044)
>          at
> org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:977)
>          at
> org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1381)
>          at
> org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1044)
>          at
> org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:977)
>          at
> org.apache.directory.server.config.LdapServerConfigReaderTest.readConfig(LdapServerConfigReaderTest.java:66)
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>          at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>          at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>          at java.lang.reflect.Method.invoke(Method.java:597)
>          at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>          at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>          at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>          at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
>          at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>          at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
>          at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
>          at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
>          at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>          at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>          at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>          at java.lang.reflect.Method.invoke(Method.java:597)
>          at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
>          at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
>
>
> This looks to me like another instance of an attempt to delete a file
> while it is still open.  This type of problem seems to be unique to the
> Windows environment.  In this case, however, it's not obvious to my why
> the file would be in use.  Is this possibly a consequence of trying to run
> tests concurrently?
Probably. It's a serious issue we already faced lately and we have fixed 
some of them, but it seems there are some remaining failures.

Sadly, none of us have a windows env to debug the code...


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Latest trunk test failures on Windows XP

Posted by fe...@gdls.com.
I've just checked out trunk and I'm getting a couple of test failures.

First ReplayCacheImplTest was failing until I changed line 100 to "Thread.
sleep( 1200 );"

Second org.apache.directory.server.config.LdapServerConfigReaderTest fails 
with an error trying to delete the contents of the work directory:

-------------------------------------------------------------------------------
Test set: org.apache.directory.server.config.LdapServerConfigReaderTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.532 sec 
<<< FAILURE!
org.apache.directory.server.config.LdapServerConfigReaderTest  Time 
elapsed: 0 sec  <<< ERROR!
java.io.IOException: Unable to delete file: C:\DOCUME~1\feezelr\LOCALS~1\
Temp\server-work\configReader\config.ldif
        at 
org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1390)
        at 
org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1044)
        at 
org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:977)
        at 
org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1381)
        at 
org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1044)
        at 
org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:977)
        at 
org.apache.directory.server.config.LdapServerConfigReaderTest.readConfig(LdapServerConfigReaderTest.java:66)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
        at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
        at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
        at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
        at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
        at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
        at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
        at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)


This looks to me like another instance of an attempt to delete a file 
while it is still open.  This type of problem seems to be unique to the 
Windows environment.  In this case, however, it's not obvious to my why 
the file would be in use.  Is this possibly a consequence of trying to run 
tests concurrently?


.


This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information.  No one else may read, print, store, copy, forward or act in reliance on it or its attachments.  If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.