This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I am starting this out as a testtools bug...could possibly be a jemmy problem depending on how things are implemented. I am making this P2 since it worked in Jelly 1 and we use this in our existing test cases. Steps to reproduce: 1. Select a number of java source files. 2. Invoke the copy() method on one of the selected files The selections should be unchanged. However what happens is the node the copy() method is invoked on is selected.
It works for me. Node root = ExplorerOperator.invoke().repositoryTab().getRootNode(); Node node1 = new Node(root, "sampledir|examples|colorpicker"); Node node2 = new Node(root, "sampledir|examples|imageviewer"); new DeleteAction().perform(new Node[] {node1, node2}); To invoke an action on more than one node you need to supply array of nodes.
Hi Jiri, I'm using something like the following: JavaNode jn1 = new JavaNode(parent, "name"); JavaNode jn2 = ... jn1.select(); jn2.addSelection() jn1.copy(); You may have the design point as copy being select + copy. I think Jelly 1 had a more logical design point which was to follow what the IDE does with existing selections when a context menu is invoked. I was going to reopen the bug, but when I realized it may be a design point question I thought I should let you decide. For me it seems easier if copy does what manually context menu + copy does. What do you think?
You are right it is a question of design point. I think Jelly 2 uses correct approach. I will comment your example and add one more: jn1.select(); jn2.addSelection() jn1.copy(); Because it is called on jn1 node, it should copy only jn1 node. To copy both nodes, you need to explicitly name both nodes: new CopyAction().perform(new Node[] {jn1, jn2}); or you can use addSelectionPath() and call perform() which uses main menu as default: jn1.select(); jn2.addSelectionPath(); new CopyAction().perform(); I think it is logical. What do other people think?
OK for design point here is how I would think about it... If you think of j1 just as java software code, then j1.copy() would only copy j1. The conceptual model I think works best is j1 is an object that is meant to model the behavior of the UI node within the IDE. Then the copy() method corresponds to what happens when the IDE user invokes a context menu on j1 and then selects the copy action in the menu. If we have a conceptual model that is different from how the user operates the IDE I think it will be hard for a test developer to keep the two straight and it will be hard for them to know what to expect a method will do. If a test writer really does just want to copy j1, it makes sense for them to follow the steps that a IDE user would take to select j1 one first, removing other selections, and then perform the copy. As an aside, I think the IDE user interface does the right thing here... if the user has made multiple selections and then invokes a context menu on one of the selected objects, the IDE works with the entire selection pointed to. Drag/drop works the same way in almost all products.
It's quite conceptual: test writer either uses atomic operations (such as select node, push popup menu), or "business logic" operations (such as compile a node or some nodes). That's the difference. Besides that there is a stability issue. Jelly2 is able to provide stable calls. I _is not_ able to care about stability of the code laying between Jelly2 invocations. So, bigger Jelly2 calls mean bigger stability. Finally, let's be honest - if test creator thinks in terms of atomic operations he should use atomic operations - it does not have anything to do with CompileAction, and especially with JavaNode.compile().