Hi Doug,
McComsey, Doug wrote:
I think I found a bug in
WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingFalse but I would
like a second opinion.
When I run the test I fail with an ItemExistsException on the first clone
statement, as follows.
public void testCloneNodesRemoveExistingFalse() throws RepositoryException {
// add mixin referenceable to node1
addMixinReferenceableToNode(node1);
// clone a node from default workspace to have the same uuid on second
workspace
workspaceW2.clone(workspace.getName(), node1.getPath(), testRootNodeW2.getPath() +
"/" + nodeName2, false);
*** I fail on the above
// clone node1 from default workspace to second workspace
try {
workspaceW2.clone(workspace.getName(), node1.getPath(), testRootNodeW2.getPath()
+ "/" + nodeName3, false);
fail("If removeExisting is false then a UUID collision should throw a
ItemExistsException");
} catch (ItemExistsException e) {
// successful
}
}
Upon examination I notice that node1 and node2 are created in both workspaces
by the setUp code. Therefore, I would expect the first clone to fail.
1. Am I seeing this correctly?
2. Does the test have a bug?
3. Should the first clone be removed since it appears to have already been done?
yes and yes ;)
but no to the third question. The setUp() method copied the nodes which
is different from cloning a node. When a node is copied it gets a new
UUID, whereas it keeps the UUID when it is cloned.
we didn't have the problem in jackrabbit because our implementation
supports same-name siblings. I've changed the test case that it does not
try to create same-name siblings. svn revision is: 291163
let me know if that works for you and thanks for reporting this issue.
regards
marcel
