Community
Participate
Working Groups
Build Identifier: M20100909-0800 The constructor CDOURIData(URI uri) gets called with uri="cdo.net4j.tcp://localhost/repo1/MAIN/@". Obviously, MAIN is the requested branch. But the code is like IPath path = new Path(uri.path()).makeAbsolute(); repositoryName = path.segment(0); resourcePath = path.removeFirstSegments(1); so, resourcePath ends up being "MAIN/@". This, in consequence, results in the following situation in CDOFileSystem$Net4j$TCP(CDOFileSystem).getStore(URI): return root.getFileStore(path); with root~= "cdo.net4j.tcp://localhost/repo1/MAIN/@" and path="MAIN/@", so that, ultimately, in FileStoreRoot.createStore(IPath, IResource) we get a rootStore being ~= "cdo.net4j.tcp://localhost/repo1/MAIN/@/MAIN/@". This can not be correct... ;) The reason seems to come from the different patterns of the URI: CDOURIData gets the branch passed in-line (see above), while it assumes the branch to be in the URI query part (see code, lines 88ff). The call stack for the creation of the CDOURIData: CDOURIData.<init>(URI) line: 153 CDOURIData.<init>(String) line: 59 CDOFileSystem$Net4j$TCP(CDOFileSystem).getStore(URI) line: 65 InternalFileSystemCore.getStore(URI) line: 107 EFS.getStore(URI) line: 470 FileStoreRoot.createStore(IPath, IResource) line: 105 FileSystemResourceManager.getStore(IResource) line: 431 FileSystemResourceManager.hasSavedDescription(IProject) line: 498 Project.open(int, IProgressMonitor) line: 970 Project.open(IProgressMonitor) line: 1040 CreateCDOProjectAction.createCDOProject(int) line: 107 The stack trace of the resulting Exception: org.eclipse.emf.cdo.common.util.CDOException: No top level ResourceNode with the name MAIN at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getRootOrTopLevelResourceNodeID(AbstractCDOView.java:473) at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getRootOrTopLevelResourceNodeID(CDOTransactionImpl.java:936) at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getResourceNodeID(AbstractCDOView.java:427) at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getResourceNodeIDChecked(AbstractCDOView.java:394) at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getResourceNodeID(AbstractCDOView.java:382) at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getResourceNode(AbstractCDOView.java:347) at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.createResourceFolder(CDOTransactionImpl.java:723) at org.eclipse.emf.cdo.internal.efs.AbstractFileStore.mkdir(AbstractFileStore.java:71) at org.eclipse.core.internal.localstore.FileSystemResourceManager.write(FileSystemResourceManager.java:998) at org.eclipse.core.internal.localstore.FileSystemResourceManager.internalWrite(FileSystemResourceManager.java:562) at org.eclipse.core.internal.resources.Project.writeDescription(Project.java:1325) at org.eclipse.core.internal.resources.Project.writeDescription(Project.java:1306) at org.eclipse.core.internal.resources.Project.create(Project.java:300) at org.eclipse.core.internal.resources.Project.create(Project.java:256) at org.eclipse.emf.cdo.internal.efs.ui.CreateCDOProjectAction.createCDOProject(CreateCDOProjectAction.java:104) Reproducible: Always Steps to Reproduce: 1. Have the plug-in org.eclipse.emf.cdo.efs (and dependencies) in your run configuration. 2. Click on the "EFS TEST" menu action.
Hi Frieder, Thank you for reporting this. CDO's *direct* EFS (ass opposed to the EFS on top of an *offline* CDOWorkspace) has never left its experimental phse. The existence of UI contributions in the core bundle is also an indication for this. In particular I realize that the use of CDOURIData has never been adjusted to more recent changes in that class. I'm about to remove these plugins from the build until they're no longer considered prototypical (no plans for that, now, that CDOWorkspace is there): org.eclipse.emf.cdo.efs org.eclipse.emf.cdo.ui.efs
Committed revision 7044: - trunk/features/org.eclipse.emf.cdo-feature - trunk/features/org.eclipse.emf.cdo.sdk-feature - trunk/plugins/org.eclipse.emf.cdo.efs - trunk/releng/org.eclipse.emf.cdo.releng
