I just filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=420502
The bug seems to affect "most" jgit operations and is not limited to one single call/feature. I looked at the jgit codebase and to my understanding the file handles in question seem to be lacking a consistent deallocation strategy (but hey, I have all of 15 minutes experience with JGIT; can I put jgit on my CV ?) It would appear to me that this bug makes the current jgit unusable on windows, since random file locking is not a good thing. Again I may be missing details due to my whopping experience with jgit. I suppose we either release with a clear warning that jgit does not work reliably on windows, or wait for some progress on the issue. I'm a bit 50/50 on this. Kristian 2013/10/28 Dennis Lundberg <denn...@apache.org>: > Thanks a lot Kristian! > > Do I understand you correctly that the leak is in the jgit Checkout command? > If so, there are probably more leaks in there since 9 of our tests > fail, each testing a different command. Some tests do succeed though. > > So how do we proceed with this? > Submit patches for jgit? > Release maven-scm as is? If so we need to inform our users about the > current limitations. > > > I agree that Windows sometimes suck when it comes to handling files, > but this is a double-edged sword. It does help us find problems like > these, that might otherwise pop up in a Windows production environment > after we release. > > Also having failing tests for one platform isn't very likely to > attract new developers from that platform. Turning it into a > never-ending downward spiral. > > > On Mon, Oct 28, 2013 at 8:22 AM, Kristian Rosenvold > <kristian.rosenv...@gmail.com> wrote: >> Finding this kind of leaks with my graciously provided OSS license of >> YJP is like stealing candy from children >> >> export MAVEN_OPTS="-Xms512m -Xmx2084m -XX:MaxPermSize=512m >> -agentpath:C:/java/yjp-12.0.6/bin/win64/yjpagent.dll=onexit=snapshot" >> c:/java/apache-maven-3.1.1/bin/mvn $@ >> >> Run test with forkMode never. >> >> Click on the "inspections" tag, run all inspections. >> >> >> A quick run with jprofiler on the surefire fork reveals that the >> un-closed file is allocated here. This even works on linux :) >> >> Kristian >> >> >> >> java.io.RandomAccessFile.<init>(File, String) >> org.eclipse.jgit.internal.storage.file.PackFile.doOpen() >> org.eclipse.jgit.internal.storage.file.PackFile.beginWindowCache() >> org.eclipse.jgit.internal.storage.file.WindowCache.load(PackFile, long) >> org.eclipse.jgit.internal.storage.file.WindowCache.getOrLoad(PackFile, long) >> org.eclipse.jgit.internal.storage.file.WindowCache.get(PackFile, long) >> org.eclipse.jgit.internal.storage.file.WindowCursor.pin(PackFile, long) >> org.eclipse.jgit.internal.storage.file.WindowCursor.copy(PackFile, >> long, byte[], int, int) >> org.eclipse.jgit.internal.storage.file.PackFile.readFully(long, >> byte[], int, int, WindowCursor) >> org.eclipse.jgit.internal.storage.file.PackFile.load(WindowCursor, long) >> org.eclipse.jgit.internal.storage.file.PackFile.get(WindowCursor, >> AnyObjectId) >> org.eclipse.jgit.internal.storage.file.ObjectDirectory.openObject1(WindowCursor, >> AnyObjectId) >> org.eclipse.jgit.internal.storage.file.FileObjectDatabase.openObjectImpl1(WindowCursor, >> AnyObjectId) >> org.eclipse.jgit.internal.storage.file.FileObjectDatabase.openObject(WindowCursor, >> AnyObjectId) >> org.eclipse.jgit.internal.storage.file.WindowCursor.open(AnyObjectId, int) >> org.eclipse.jgit.lib.ObjectReader.open(AnyObjectId) >> org.eclipse.jgit.revwalk.RevWalk.parseAny(AnyObjectId) >> org.eclipse.jgit.revwalk.RevWalk.parseCommit(AnyObjectId) >> org.eclipse.jgit.api.CloneCommand.parseCommit(Repository, Ref) >> org.eclipse.jgit.api.CloneCommand.checkout(Repository, FetchResult) >> org.eclipse.jgit.api.CloneCommand.call() >> org.apache.maven.scm.provider.git.jgit.command.checkout.JGitCheckOutCommand.executeCheckOutCommand(ScmProviderRepository, >> ScmFileSet, ScmVersion, boolean) >> org.apache.maven.scm.command.checkout.AbstractCheckOutCommand.executeCommand(ScmProviderRepository, >> ScmFileSet, CommandParameters) >> org.apache.maven.scm.command.AbstractCommand.execute(ScmProviderRepository, >> ScmFileSet, CommandParameters) >> org.apache.maven.scm.provider.git.AbstractGitScmProvider.executeCommand(GitCommand, >> ScmProviderRepository, ScmFileSet, CommandParameters) >> org.apache.maven.scm.provider.git.AbstractGitScmProvider.checkout(ScmProviderRepository, >> ScmFileSet, CommandParameters) >> org.apache.maven.scm.provider.AbstractScmProvider.checkOut(ScmRepository, >> ScmFileSet, ScmVersion, boolean) >> org.apache.maven.scm.provider.AbstractScmProvider.checkOut(ScmRepository, >> ScmFileSet) >> org.apache.maven.scm.manager.AbstractScmManager.checkOut(ScmRepository, >> ScmFileSet) >> org.apache.maven.scm.tck.command.tag.TagCommandTckTest.testTagCommandTest() >> junit.framework.TestSuite.run(TestResult) >> org.junit.internal.runners.JUnit38ClassRunner.run(RunNotifier) >> org.apache.maven.surefire.junit4.JUnit4Provider.execute(Class, >> RunNotifier, String[]) >> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(Class, >> RunListener, RunNotifier) >> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(Object) >> java.lang.reflect.Method.invoke(Object, Object[]) >> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(Object, >> Method, Object[]) >> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(Object) >> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(Object, >> ClassLoader, Object, ProviderConfiguration, boolean, >> StartupConfiguration, boolean) >> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(DefaultScanResult) >> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(ProviderInfo, >> DefaultScanResult) >> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(DefaultScanResult) >> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute() >> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(MavenSession, >> MojoExecution) >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MavenSession, >> MojoExecution, ProjectIndex, DependencyContext) >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MavenSession, >> MojoExecution, ProjectIndex, DependencyContext, PhaseRecorder) >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MavenSession, >> List, ProjectIndex) >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(MavenSession, >> MavenSession, ReactorContext, MavenProject, TaskSegment) >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(MavenSession, >> ReactorContext, MavenProject, TaskSegment) >> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(MavenSession, >> ReactorContext, ProjectBuildList, List, ReactorBuildStatus) >> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(MavenSession) >> org.apache.maven.DefaultMaven.doExecute(MavenExecutionRequest) >> org.apache.maven.DefaultMaven.execute(MavenExecutionRequest) >> org.apache.maven.cli.MavenCli.execute(MavenCli$CliRequest) >> org.apache.maven.cli.MavenCli.doMain(MavenCli$CliRequest) >> org.apache.maven.cli.MavenCli.main(String[], ClassWorld) >> java.lang.reflect.Method.invoke(Object, Object[]) >> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(String[]) >> org.codehaus.plexus.classworlds.launcher.Launcher.launch(String[]) >> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(String[]) >> org.codehaus.plexus.classworlds.launcher.Launcher.main(String[]) >> >> 2013/10/28 Olivier Lamy <ol...@apache.org>: >>> Windauze one of the biggest pain of my life... >>> So few people trying to fix that (perso I don't have any windauze env). >>> And it looks no success. >>> >>> So what else now? Not releasing that until we get a fix from jgit. >>> AFAICS the issue is because after testing we try to delete the local clone. >>> Is it really something blocker? I mean does our users delete their >>> local clone after doing a release or using scm api? >>> >>> >>> >>> >>> On 26 October 2013 21:04, Robert Scholte <rfscho...@apache.org> wrote: >>>> Hi Domi, >>>> >>>> I've given the tests another spin, but still with the same results. >>>> I found this thread: >>>> http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01959.html >>>> It seems to expose the same kind of problem. >>>> I've tried a couple of things, but still couldn't delete during the test. >>>> Maybe it gives you some inspiration to fix this. >>>> >>>> Robert >>>> >>>> >>>> Op Sat, 26 Oct 2013 11:15:59 +0200 schreef domi <d...@fortysix.ch>: >>>> >>>> >>>>> I updated jgit to the newest version - on MAC everything is still OK, but >>>>> as I don't have windows box, I can't verify it… >>>>> Robert, can you try it again with this version? >>>>> /Domi >>>>> >>>>> >>>>> On 25.10.2013, at 23:51, "Robert Scholte" <rfscho...@apache.org> wrote: >>>>> >>>>>> I can confirm the same issue on Windows 7. >>>>>> Not being able to delete a file often means that the outputstream wasn't >>>>>> closed after writing. >>>>>> The file seems to be generated by jgit, so I'm wondering if there's >>>>>> something which can be done by the scm-provider. >>>>>> >>>>>> Robert >>>>>> >>>>>> Op Fri, 25 Oct 2013 21:03:36 +0200 schreef Dennis Lundberg >>>>>> <denn...@apache.org>: >>>>>> >>>>>>> -1 at the moment. >>>>>>> >>>>>>> The unit tests for the new jgit provider fails on Windows. >>>>>>> >>>>>>> Here's the surefire summary: >>>>>>> >>>>>>> Tests in error: >>>>>>> JGitBranchCommandTckTest>BranchCommandTckTest.testBranchCommandTest:77 >>>>>>> ╗ IO Fi... >>>>>>> >>>>>>> JGitChangeLogCommandTckTest>ScmTckTestCase.setUp:106->ScmTestCase.setUp:65 >>>>>>> ╗ IO >>>>>>> >>>>>>> JGitCheckInCommandTckTest>ScmTckTestCase.setUp:106->ScmTestCase.setUp:65 >>>>>>> ╗ IO ... >>>>>>> >>>>>>> JGitCheckInCommandTckTest>ScmTckTestCase.setUp:106->ScmTestCase.setUp:65 >>>>>>> ╗ IO ... >>>>>>> >>>>>>> JGitCheckOutCommandTckTest>ScmTckTestCase.setUp:106->ScmTestCase.setUp:65 >>>>>>> ╗ >>>>>>> IO >>>>>>> JGitDiffCommandTckTest>ScmTckTestCase.setUp:106->ScmTestCase.setUp:65 >>>>>>> ╗ IO Fil... >>>>>>> >>>>>>> JGitRemoteInfoCommandTckTest>ScmTckTestCase.setUp:106->ScmTestCase.setUp:65 >>>>>>> ╗ IO >>>>>>> JGitStatusCommandTckTest>ScmTckTestCase.setUp:106->ScmTestCase.setUp:65 >>>>>>> ╗ IO F... >>>>>>> JGitTagCommandTckTest>ScmTckTestCase.setUp:106->ScmTestCase.setUp:65 >>>>>>> ╗ IO File... >>>>>>> >>>>>>> Tests run: 9, Failures: 0, Errors: 9, Skipped: 0 >>>>>>> >>>>>>> >>>>>>> Here is the first part of the build output I get: >>>>>>> >>>>>>> Running >>>>>>> org.apache.maven.scm.provider.git.jgit.command.branch.JGitBranchCommandTckTest >>>>>>> [INFO] cloning [master] to >>>>>>> >>>>>>> G:\apache\maven\git\maven-scm\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-jgit\target\scm-test\working-copy >>>>>>> remote: Counting objects: 1 >>>>>>> remote: Finding sources: 100% (11/11) >>>>>>> remote: Getting sizes: 100% (10/10) >>>>>>> remote: Compressing objects: 100% (363/363) >>>>>>> Receiving objects: 100% (11/11) >>>>>>> Updating references: 100% (1/1) >>>>>>> [INFO] fetch url: >>>>>>> >>>>>>> file:///G:/apache/maven/git/maven-scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/target/scm-test/repository >>>>>>> [INFO] push url: >>>>>>> >>>>>>> file:///G:/apache/maven/git/maven-scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/target/scm-test/repository >>>>>>> [INFO] checkout [master] at >>>>>>> >>>>>>> G:\apache\maven\git\maven-scm\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-jgit\target\scm-test\working-copy >>>>>>> [INFO] created [refs/heads/test-branch] >>>>>>> [INFO] push branch [test-branch] to remote... >>>>>>> [INFO] fetch url: >>>>>>> >>>>>>> file:///G:/apache/maven/git/maven-scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/target/scm-test/repository >>>>>>> [INFO] push url: >>>>>>> >>>>>>> file:///G:/apache/maven/git/maven-scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/target/scm-test/repository >>>>>>> [INFO] OK - RemoteRefUpdate[remoteName=refs/heads/test-branch, OK, >>>>>>> (null)...92f139dfec4d1dfb79c3cd2f94e83bf13129668b, fastForward, >>>>>>> srcRef=refs/heads/test-branch, message=null] >>>>>>> [INFO] commit done: commit message >>>>>>> [INFO] push changes to remote... refs/heads/master:refs/heads/master >>>>>>> [INFO] fetch url: >>>>>>> >>>>>>> file:///G:/apache/maven/git/maven-scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/target/scm-test/repository >>>>>>> [INFO] push url: >>>>>>> >>>>>>> file:///G:/apache/maven/git/maven-scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/target/scm-test/repository >>>>>>> [INFO] OK - RemoteRefUpdate[remoteName=refs/heads/master, OK, >>>>>>> (null)...dad31f52c2e81b71c2b4954ec9e2bc6dacfe9bef, fastForward, >>>>>>> srcRef=refs/heads/master, message=null] >>>>>>> [INFO] cloning [master] to >>>>>>> >>>>>>> G:\apache\maven\git\maven-scm\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-jgit\target\scm-test\assertion-copy >>>>>>> remote: Counting objects: 1 >>>>>>> remote: Finding sources: 100% (14/14) >>>>>>> remote: Getting sizes: 100% (12/12) >>>>>>> remote: Compressing objects: 100% (363/363) >>>>>>> Receiving objects: 100% (14/14) >>>>>>> Resolving deltas: 100% (1/1) >>>>>>> Updating references: 100% (2/2) >>>>>>> [INFO] fetch url: >>>>>>> >>>>>>> file:///G:/apache/maven/git/maven-scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/target/scm-test/repository >>>>>>> [INFO] push url: >>>>>>> >>>>>>> file:///G:/apache/maven/git/maven-scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/target/scm-test/repository >>>>>>> [INFO] checkout [master] at >>>>>>> >>>>>>> G:\apache\maven\git\maven-scm\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-jgit\target\scm-test\assertion-copy >>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.656 >>>>>>> sec <<< FAILURE! - in >>>>>>> >>>>>>> org.apache.maven.scm.provider.git.jgit.command.branch.JGitBranchCommandTckTest >>>>>>> >>>>>>> testBranchCommandTest(org.apache.maven.scm.provider.git.jgit.command.branch.JGitBranchCommandTckTest) >>>>>>> Time elapsed: 5.602 sec <<< ERROR! >>>>>>> java.io.IOException: File >>>>>>> >>>>>>> G:\apache\maven\git\maven-scm\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-jgit\target\scm-test\assertion-copy\.git\objects\pack\pack-a06d224d673591806e6a66da6d8f27915e18184d.pack >>>>>>> unable to >>>>>>> be deleted. >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1413) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1673) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1618) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1401) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1673) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1618) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1401) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1673) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1618) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1401) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1673) >>>>>>> at >>>>>>> org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1618) >>>>>>> at >>>>>>> org.apache.maven.scm.tck.command.branch.BranchCommandTckTest.testBranchCommandTest(BranchCommandTckTest.java:77) >>>>>>> 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:592) >>>>>>> at junit.framework.TestCase.runTest(TestCase.java:168) >>>>>>> at junit.framework.TestCase.runBare(TestCase.java:134) >>>>>>> at junit.framework.TestResult$1.protect(TestResult.java:110) >>>>>>> at junit.framework.TestResult.runProtected(TestResult.java:128) >>>>>>> at junit.framework.TestResult.run(TestResult.java:113) >>>>>>> at junit.framework.TestCase.run(TestCase.java:124) >>>>>>> at junit.framework.TestSuite.runTest(TestSuite.java:243) >>>>>>> at junit.framework.TestSuite.run(TestSuite.java:238) >>>>>>> at >>>>>>> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) >>>>>>> at >>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) >>>>>>> at >>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) >>>>>>> at >>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) >>>>>>> at >>>>>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) >>>>>>> at >>>>>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) >>>>>>> at >>>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) >>>>>>> >>>>>>> On Thu, Oct 24, 2013 at 5:35 AM, Olivier Lamy <ol...@apache.org> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> We fixed 9 issues. The new feature is the jgit provider (based on >>>>>>>> jgit). >>>>>>>> Details: >>>>>>>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18783 >>>>>>>> >>>>>>>> Staging repository: >>>>>>>> https://repository.apache.org/content/repositories/maven-027/ >>>>>>>> Staged site: http://maven.apache.org/scm-archives/scm-LATEST/ >>>>>>>> >>>>>>>> Sources release: >>>>>>>> >>>>>>>> https://repository.apache.org/content/repositories/maven-027/org/apache/maven/scm/maven-scm/1.9/maven-scm-1.9-source-release.zip >>>>>>>> >>>>>>>> Vote open for 72H >>>>>>>> >>>>>>>> [+1] >>>>>>>> [0] >>>>>>>> [-1] >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> -- >>>>>>>> Olivier Lamy >>>>>>>> Ecetera: http://ecetera.com.au >>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> >>> >>> -- >>> Olivier Lamy >>> Ecetera: http://ecetera.com.au >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
