Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » Drag and Drop on a diagram creates EditPart in wrong place
Drag and Drop on a diagram creates EditPart in wrong place [message #223049] Fri, 27 March 2009 21:42 Go to next message
Eclipse UserFriend
Originally posted by: mklinchin.yahoo.com

Hi All,

I implemented drag and drop from common navigator to a GMF diagram. To do
this I installed XxxDragDropEditPolicy for the target edit part where I
return my own CreateElementCommand in
XxxDragDropEditPolicy.getDropObjectsCommand . The command operates with
model, creates model elements and makes relationships between them.
Everything works fine.

The problem is that the element I create appears in some random places on
the diagram. I would rather say that diagram calculates the position of
the new Edit Part. I want it to appear right under the mouse pointer that
performed the drop. The diagram sometimes is pretty large so it is hard to
find the dropped element. So you are looking for empty space to drop the
element but it appears on the other side of the diagram.

How can I make the element appear under the mouse pointer at the time of
drop or at least scroll the diagram to the newly created element so it
will be in the center?

Thank you,
Igor
Re: Drag and Drop on a diagram creates EditPart in wrong place [message #223588 is a reply to message #223049] Tue, 31 March 2009 11:05 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Igor,

Try calling org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.createViewsAndArrangeCommand()
- at least this method is called by GMf-generated code handling shortcuts
creation on D&D from ProjectExplorer and it looks like an element will be
created just below the mouse.

-----------------
Alex Shatalin
Re: Drag and Drop on a diagram creates EditPart in wrong place [message #224566 is a reply to message #223588] Mon, 06 April 2009 21:38 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mklinchin.yahoo.com

Hi Alex,

Thank you very much for your suggestion. It helped a lot. After I started
to build my command with createViewsAndArrangeCommand method my
CREATION_ROLE policy installed for Diagram model element started to
receive calls for getCommand method where I can get exact mouse location
in right coordinates. I apply these coordinates in getCreateCommand of the
same policy where location is always (-1, -1).

I still do not understand why location gets broken in getCreateCommand but
at least now I have a way to set correct location. When I create new
element by picking a tool from palette the location is correct here.
Bottom line is that my drag and drops create object right under the mouse
cursor.

Igor

On Tue, 31 Mar 2009 11:05:33 +0000, Alex Shatalin wrote:

> Hello Igor,
>
> Try calling org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.createViewsAndArrangeCommand()
> - at least this method is called by GMf-generated code handling shortcuts
> creation on D&D from ProjectExplorer and it looks like an element will be
> created just below the mouse.
>
> -----------------
> Alex Shatalin
Re: Drag and Drop on a diagram creates EditPart in wrong place [message #224993 is a reply to message #224566] Wed, 08 April 2009 15:06 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban DugueperouxFriend
Messages: 472
Registered: July 2009
Senior Member
Hi Igor,

I want to have same feature but from a view. Indeed I want DnD EObject
object from one view to my GMF editor I have setted a
DiagramDropTargetListener on my DiagramDocumentEditor. This
DropTargetListener have a createTargetRequest() creating a
DropObjectsRequest. By default createViewsAndArrangeCommand method is
called in DiagramDragDropEditPolicy then not needed to create a custom
DiagramDragDropEditPolicy. Do you really need a custom
DiagramDragDropEditPolicy? Do you do a particular action in handleDrop
of your DiagramDropTargetListener ?

Can you give me some sample code?

Thanks.

Igor Klinchin a écrit :
> Hi Alex,
>
> Thank you very much for your suggestion. It helped a lot. After I started
> to build my command with createViewsAndArrangeCommand method my
> CREATION_ROLE policy installed for Diagram model element started to
> receive calls for getCommand method where I can get exact mouse location
> in right coordinates. I apply these coordinates in getCreateCommand of the
> same policy where location is always (-1, -1).
>
> I still do not understand why location gets broken in getCreateCommand but
> at least now I have a way to set correct location. When I create new
> element by picking a tool from palette the location is correct here.
> Bottom line is that my drag and drops create object right under the mouse
> cursor.
>
> Igor
>
> On Tue, 31 Mar 2009 11:05:33 +0000, Alex Shatalin wrote:
>
>> Hello Igor,
>>
>> Try calling org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.createViewsAndArrangeCommand()
>> - at least this method is called by GMf-generated code handling shortcuts
>> creation on D&D from ProjectExplorer and it looks like an element will be
>> created just below the mouse.
>>
>> -----------------
>> Alex Shatalin
>
Re: Drag and Drop on a diagram creates EditPart in wrong place [message #225360 is a reply to message #224993] Thu, 09 April 2009 23:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mklinchin.yahoo.com

Hi Esteban,

I have getObjectsBeingDropped() method overriden in my
DiagramDropTargetListener. Here I get

ISelection selection = LocalSelectionTransfer.getTransfer().getSelection();

then I check whether all objects are valid (I have objects that could be
dropped on the diagram and others that could be not) and return
((IStructuredSelection) selection).toList();

createTargetRequest() just return super.createTargetRequest();

I also have DiagramDragDropEditPolicy with overridden
getDropCommand(ChangeBoundsRequest request). Here I retrieve objects from
DropObjectsRequest and make a CompoundCommand with a Command for each of
the objects from there. Each command (for individual object) builds new
object to be dropped (in my case I build totally new object since I dnd
unrelated stuff like file from file system or object from different model
- you may need to just copy the original object or use it as it is),
create a command that will insert this object into the model and builds a
composite command like this:

CreateElementRequest req = new CreateElementRequest( elementType );
MyDropCommand dropCommand = new MyDropCommand(req);
ArrayList viewDescriptors = new ArrayList();
viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
new EObjectAdapter(MyNewObject),
Node.class, null, preferencesHint));

Command command = createViewsAndArrangeCommand(dropRequest,
viewDescriptors);
if( command != null ) {
return new ICommandProxy(dropCommand).chain( command );
}

If you already have your object in you model (like you dnd from view that
displays the same model so that editor already has this object) you may
want to return command; only - no object needs to be inserted into the
diagram. Otherwise, return command; will insert an object to the diagram
but not in model.

You can debug this piece so that
DiagramDragDropEditPolicy.getDropCommand() should return not null command
and viewDescriptors should contain a descriptor of some valid object from
the model.

I do no know whether you can leave default implementation of
DiagramDragDropEditPolicy. It seems to me that you can in case you dnd
objects of the same model. I have different situation, I dnd objects
unrelated to the model so I had to replace the way how model objects are
constructed. In any case, I think, you should install
DiagramDragDropEditPolicy into your Diagram implementation. Also it might
be that the problem is with DiagramDropTargetListener.

Igor

On Wed, 08 Apr 2009 17:06:04 +0200, Esteban DUGUEPEROUX wrote:

> Hi Igor,
>
> I want to have same feature but from a view. Indeed I want DnD EObject
> object from one view to my GMF editor I have setted a
> DiagramDropTargetListener on my DiagramDocumentEditor. This
> DropTargetListener have a createTargetRequest() creating a
> DropObjectsRequest. By default createViewsAndArrangeCommand method is
> called in DiagramDragDropEditPolicy then not needed to create a custom
> DiagramDragDropEditPolicy. Do you really need a custom
> DiagramDragDropEditPolicy? Do you do a particular action in handleDrop
> of your DiagramDropTargetListener ?
>
> Can you give me some sample code?
>
> Thanks.
>
> Igor Klinchin a écrit :
>> Hi Alex,
>>
>> Thank you very much for your suggestion. It helped a lot. After I started
>> to build my command with createViewsAndArrangeCommand method my
>> CREATION_ROLE policy installed for Diagram model element started to
>> receive calls for getCommand method where I can get exact mouse location
>> in right coordinates. I apply these coordinates in getCreateCommand of the
>> same policy where location is always (-1, -1).
>>
>> I still do not understand why location gets broken in getCreateCommand but
>> at least now I have a way to set correct location. When I create new
>> element by picking a tool from palette the location is correct here.
>> Bottom line is that my drag and drops create object right under the mouse
>> cursor.
>>
>> Igor
>>
>> On Tue, 31 Mar 2009 11:05:33 +0000, Alex Shatalin wrote:
>>
>>> Hello Igor,
>>>
>>> Try calling org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.createViewsAndArrangeCommand()
>>> - at least this method is called by GMf-generated code handling shortcuts
>>> creation on D&D from ProjectExplorer and it looks like an element will be
>>> created just below the mouse.
>>>
>>> -----------------
>>> Alex Shatalin
>>
Re: Drag and Drop on a diagram creates EditPart in wrong place [message #225754 is a reply to message #225360] Tue, 14 April 2009 09:10 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban DugueperouxFriend
Messages: 472
Registered: July 2009
Senior Member
Hi Igor,

Thanks for you help, now I can create new elements(View with
corresponding model element : CreateViewAndElementRequest)
My code is similar to http://wiki.eclipse.org/index.php/GMF_Tips (first
tip).
But when I dropped a file to my diagram I would like to initialize my
new created element with property values according to my dropped file. I
could chain my first Command resulting of my CreateViewAndElementRequest
with a second command from a SetRequest but constructor of SetRequest
need the model element to change property then How to fetch created
element from my CreateViewAndElementRequest?

Also in GMF API, we can see two package with request :

- org.eclipse.gmf.runtime.emf.type.core.requests
- org.eclipse.gmf.runtime.diagram.ui.requests

EditPart.getCommand(Request) or in
DiagramDragDropEditPolicy.getCommand(Request) seems to accept only
requests from second package then What are requests from first package?

CreateViewAndElementRequest belongs to first package while SetRequest
belongs to second.
But to solve this, we can find in
org.eclipse.gmf.runtime.emf.type.core.commands package a SetValueCommand
which accept a SetRequest in constructor and with ICommandProxy we can
wrap the SetValueCommand to a org.eclipse.gef.commands.Command.

This last think is correct?


Also besides to DnD file, I would like to DnD EObject from a View to my
diagram, principe seem similar but instead of use SetRequest and
SetValueCommand I could use MoveRequest and MoveElementsCommand, correct?
But in my DiagramDragDropEditPolicy, I call
DiagramDragDropEditPolicy.getHostObject() method to fetch model element
to pass my MoveRequest constructor but getHostObject() return null.
Why this return null in my EditPolicy?

Igor Klinchin a écrit :
> Hi Esteban,
>
> I have getObjectsBeingDropped() method overriden in my
> DiagramDropTargetListener. Here I get
>
> ISelection selection = LocalSelectionTransfer.getTransfer().getSelection();
>
> then I check whether all objects are valid (I have objects that could be
> dropped on the diagram and others that could be not) and return
> ((IStructuredSelection) selection).toList();
>
> createTargetRequest() just return super.createTargetRequest();
>
> I also have DiagramDragDropEditPolicy with overridden
> getDropCommand(ChangeBoundsRequest request). Here I retrieve objects from
> DropObjectsRequest and make a CompoundCommand with a Command for each of
> the objects from there. Each command (for individual object) builds new
> object to be dropped (in my case I build totally new object since I dnd
> unrelated stuff like file from file system or object from different model
> - you may need to just copy the original object or use it as it is),
> create a command that will insert this object into the model and builds a
> composite command like this:
>
> CreateElementRequest req = new CreateElementRequest( elementType );
> MyDropCommand dropCommand = new MyDropCommand(req);
> ArrayList viewDescriptors = new ArrayList();
> viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
> new EObjectAdapter(MyNewObject),
> Node.class, null, preferencesHint));
>
> Command command = createViewsAndArrangeCommand(dropRequest,
> viewDescriptors);
> if( command != null ) {
> return new ICommandProxy(dropCommand).chain( command );
> }
>
> If you already have your object in you model (like you dnd from view that
> displays the same model so that editor already has this object) you may
> want to return command; only - no object needs to be inserted into the
> diagram. Otherwise, return command; will insert an object to the diagram
> but not in model.
>
> You can debug this piece so that
> DiagramDragDropEditPolicy.getDropCommand() should return not null command
> and viewDescriptors should contain a descriptor of some valid object from
> the model.
>
> I do no know whether you can leave default implementation of
> DiagramDragDropEditPolicy. It seems to me that you can in case you dnd
> objects of the same model. I have different situation, I dnd objects
> unrelated to the model so I had to replace the way how model objects are
> constructed. In any case, I think, you should install
> DiagramDragDropEditPolicy into your Diagram implementation. Also it might
> be that the problem is with DiagramDropTargetListener.
>
> Igor
>
> On Wed, 08 Apr 2009 17:06:04 +0200, Esteban DUGUEPEROUX wrote:
>
>> Hi Igor,
>>
>> I want to have same feature but from a view. Indeed I want DnD EObject
>> object from one view to my GMF editor I have setted a
>> DiagramDropTargetListener on my DiagramDocumentEditor. This
>> DropTargetListener have a createTargetRequest() creating a
>> DropObjectsRequest. By default createViewsAndArrangeCommand method is
>> called in DiagramDragDropEditPolicy then not needed to create a custom
>> DiagramDragDropEditPolicy. Do you really need a custom
>> DiagramDragDropEditPolicy? Do you do a particular action in handleDrop
>> of your DiagramDropTargetListener ?
>>
>> Can you give me some sample code?
>>
>> Thanks.
>>
>> Igor Klinchin a écrit :
>>> Hi Alex,
>>>
>>> Thank you very much for your suggestion. It helped a lot. After I started
>>> to build my command with createViewsAndArrangeCommand method my
>>> CREATION_ROLE policy installed for Diagram model element started to
>>> receive calls for getCommand method where I can get exact mouse location
>>> in right coordinates. I apply these coordinates in getCreateCommand of the
>>> same policy where location is always (-1, -1).
>>>
>>> I still do not understand why location gets broken in getCreateCommand but
>>> at least now I have a way to set correct location. When I create new
>>> element by picking a tool from palette the location is correct here.
>>> Bottom line is that my drag and drops create object right under the mouse
>>> cursor.
>>>
>>> Igor
>>>
>>> On Tue, 31 Mar 2009 11:05:33 +0000, Alex Shatalin wrote:
>>>
>>>> Hello Igor,
>>>>
>>>> Try calling org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.createViewsAndArrangeCommand()
>>>> - at least this method is called by GMf-generated code handling shortcuts
>>>> creation on D&D from ProjectExplorer and it looks like an element will be
>>>> created just below the mouse.
>>>>
>>>> -----------------
>>>> Alex Shatalin
>
Re: Drag and Drop on a diagram creates EditPart in wrong place [message #227182 is a reply to message #225754] Thu, 23 April 2009 14:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mklinchin.yahoo.com

Hi Esteban,

On Tue, 14 Apr 2009 11:10:52 +0200, Esteban DUGUEPEROUX wrote:

> Hi Igor,
>
> Thanks for you help, now I can create new elements(View with
> corresponding model element : CreateViewAndElementRequest)
> My code is similar to http://wiki.eclipse.org/index.php/GMF_Tips (first
> tip).
> But when I dropped a file to my diagram I would like to initialize my
> new created element with property values according to my dropped file. I
> could chain my first Command resulting of my CreateViewAndElementRequest
> with a second command from a SetRequest but constructor of SetRequest
> need the model element to change property then How to fetch created
> element from my CreateViewAndElementRequest?

I think that you need to create your own command (CreateElementCommand)
based on the CreateElementRequest (and create this CreateElementRequest
before it also). The command should build the new object and in its
doDefaultElementCreation method add the object to the model. It could be
done in DiagramDragDropEditPolicy like this:

IGraphicalEditPart host = (IGraphicalEditPart) getHost();
EObject hostElement = host.resolveSemanticElement();

(...)

CreateElementRequest req = new CreateElementRequest( elementType );
req.setContainmentFeature(...);
req.setContainer(hostElement);
req.setEditingDomain(host.getEditingDomain());
req.setNewElement(<... new object ...>);

(...)

ArrayList viewDescriptors = new ArrayList();
viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
<... new object ...>,
Node.class, null, preferencesHint));

MyDropTypeCommand dropCommand = new MyDropCommand(req);
Command command = createViewsAndArrangeCommand(request, viewDescriptors);
return new ICommandProxy(dropCommand).chain( command );

It seems to me that there are many ways to do it and I am not sure that I
have the most efficient one. It was kind of a solution that worked for me.

>
> Also in GMF API, we can see two package with request :
>
> - org.eclipse.gmf.runtime.emf.type.core.requests
> - org.eclipse.gmf.runtime.diagram.ui.requests
>
> EditPart.getCommand(Request) or in
> DiagramDragDropEditPolicy.getCommand(Request) seems to accept only
> requests from second package then What are requests from first package?

The first one is used in the other command that you will need to implement
extending CreateElementCommand in order to construct and add completely
new object to the diagram. Here is a constructor for such command that you
will need to call to initialize this command:

public CreateElementCommand(CreateElementRequest request);

This request is from org.eclipse.gmf.runtime.emf.type.core.requests;

Basically request in DiagramDragDropEditPolicy.getDropObjectsCommand is
from *.diagram.ui.requests. CreateElementRequest for your own command that
will build the object is from *.runtime.emf.type.core.requests.



>
> CreateViewAndElementRequest belongs to first package while SetRequest
> belongs to second.
> But to solve this, we can find in
> org.eclipse.gmf.runtime.emf.type.core.commands package a SetValueCommand
> which accept a SetRequest in constructor and with ICommandProxy we can
> wrap the SetValueCommand to a org.eclipse.gef.commands.Command.
>
> This last think is correct?

I think that we are talking about similar things.

>
>
> Also besides to DnD file, I would like to DnD EObject from a View to my
> diagram, principe seem similar but instead of use SetRequest and
> SetValueCommand I could use MoveRequest and MoveElementsCommand, correct?

I think that MoveRequest and MoveElementCommand are about moving objects
inside a diagram. It is like changing coordinates of a figure on the
diagram. I might be wrong in this.

> But in my DiagramDragDropEditPolicy, I call
> DiagramDragDropEditPolicy.getHostObject() method to fetch model element
> to pass my MoveRequest constructor but getHostObject() return null.
> Why this return null in my EditPolicy?

It is interesting that I also failed to use MoveElementsCommand with
similar problems but I was sure that it is used to move figures inside a
diagram. In this sence I explained it in the way that I could not move the
figure in DiagramDragDropEditPolicy becuase it does not exist yet. It will
be added to the diagram after my command that I construct here (from newly
constructed request) will add it to the model and
createViewsAndArrangeCommand will create a figure on the diagram. I tried
to chain this MoveElementsCommand but with no success.

I am sorry that I reply that late, I need to check old posts more often. I
hope this discussion will help you to understand better the situation
inside d&d. I missed such discussions while I was implementing my d&d and
messsage from Alex helped me a lot to dig to the right place.

Thank you,
Igor


>
> Igor Klinchin a écrit :
>> Hi Esteban,
>>
>> I have getObjectsBeingDropped() method overriden in my
>> DiagramDropTargetListener. Here I get
>>
>> ISelection selection = LocalSelectionTransfer.getTransfer().getSelection();
>>
>> then I check whether all objects are valid (I have objects that could be
>> dropped on the diagram and others that could be not) and return
>> ((IStructuredSelection) selection).toList();
>>
>> createTargetRequest() just return super.createTargetRequest();
>>
>> I also have DiagramDragDropEditPolicy with overridden
>> getDropCommand(ChangeBoundsRequest request). Here I retrieve objects from
>> DropObjectsRequest and make a CompoundCommand with a Command for each of
>> the objects from there. Each command (for individual object) builds new
>> object to be dropped (in my case I build totally new object since I dnd
>> unrelated stuff like file from file system or object from different model
>> - you may need to just copy the original object or use it as it is),
>> create a command that will insert this object into the model and builds a
>> composite command like this:
>>
>> CreateElementRequest req = new CreateElementRequest( elementType );
>> MyDropCommand dropCommand = new MyDropCommand(req);
>> ArrayList viewDescriptors = new ArrayList();
>> viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
>> new EObjectAdapter(MyNewObject),
>> Node.class, null, preferencesHint));
>>
>> Command command = createViewsAndArrangeCommand(dropRequest,
>> viewDescriptors);
>> if( command != null ) {
>> return new ICommandProxy(dropCommand).chain( command );
>> }
>>
>> If you already have your object in you model (like you dnd from view that
>> displays the same model so that editor already has this object) you may
>> want to return command; only - no object needs to be inserted into the
>> diagram. Otherwise, return command; will insert an object to the diagram
>> but not in model.
>>
>> You can debug this piece so that
>> DiagramDragDropEditPolicy.getDropCommand() should return not null command
>> and viewDescriptors should contain a descriptor of some valid object from
>> the model.
>>
>> I do no know whether you can leave default implementation of
>> DiagramDragDropEditPolicy. It seems to me that you can in case you dnd
>> objects of the same model. I have different situation, I dnd objects
>> unrelated to the model so I had to replace the way how model objects are
>> constructed. In any case, I think, you should install
>> DiagramDragDropEditPolicy into your Diagram implementation. Also it might
>> be that the problem is with DiagramDropTargetListener.
>>
>> Igor
>>
>> On Wed, 08 Apr 2009 17:06:04 +0200, Esteban DUGUEPEROUX wrote:
>>
>>> Hi Igor,
>>>
>>> I want to have same feature but from a view. Indeed I want DnD EObject
>>> object from one view to my GMF editor I have setted a
>>> DiagramDropTargetListener on my DiagramDocumentEditor. This
>>> DropTargetListener have a createTargetRequest() creating a
>>> DropObjectsRequest. By default createViewsAndArrangeCommand method is
>>> called in DiagramDragDropEditPolicy then not needed to create a custom
>>> DiagramDragDropEditPolicy. Do you really need a custom
>>> DiagramDragDropEditPolicy? Do you do a particular action in handleDrop
>>> of your DiagramDropTargetListener ?
>>>
>>> Can you give me some sample code?
>>>
>>> Thanks.
>>>
>>> Igor Klinchin a écrit :
>>>> Hi Alex,
>>>>
>>>> Thank you very much for your suggestion. It helped a lot. After I started
>>>> to build my command with createViewsAndArrangeCommand method my
>>>> CREATION_ROLE policy installed for Diagram model element started to
>>>> receive calls for getCommand method where I can get exact mouse location
>>>> in right coordinates. I apply these coordinates in getCreateCommand of the
>>>> same policy where location is always (-1, -1).
>>>>
>>>> I still do not understand why location gets broken in getCreateCommand but
>>>> at least now I have a way to set correct location. When I create new
>>>> element by picking a tool from palette the location is correct here.
>>>> Bottom line is that my drag and drops create object right under the mouse
>>>> cursor.
>>>>
>>>> Igor
>>>>
>>>> On Tue, 31 Mar 2009 11:05:33 +0000, Alex Shatalin wrote:
>>>>
>>>>> Hello Igor,
>>>>>
>>>>> Try calling org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.createViewsAndArrangeCommand()
>>>>> - at least this method is called by GMf-generated code handling shortcuts
>>>>> creation on D&D from ProjectExplorer and it looks like an element will be
>>>>> created just below the mouse.
>>>>>
>>>>> -----------------
>>>>> Alex Shatalin
>>
Re: Drag and Drop on a diagram creates EditPart in wrong place [message #227716 is a reply to message #227182] Mon, 27 April 2009 16:19 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban DugueperouxFriend
Messages: 472
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070903030304010706070009
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Igor,

Thanks for your reply, I tried your code :
I have overrided "Command getDropFileCommand(DropObjectsRequest)" method
in my DiagramDragDropEditPolicy as following :

protected Command getDropFileCommand(DropObjectsRequest dropRequest) {
Object nextObject = dropRequest.getObjects().get(0);

List<CreateViewRequest.ViewDescriptor> viewDescriptors = new
ArrayList<CreateViewRequest.ViewDescriptor>();

MDAProjectEditPart editPart = (MDAProjectEditPart) getHost();
String fileName = (String) nextObject;
File file = new File(fileName);
String name = file.getName();

IGraphicalEditPart host = (IGraphicalEditPart) getHost();
EObject hostElement = host.resolveSemanticElement();
IElementType elementType = MdaElementTypes.Model_1004;
CreateElementRequest req = new CreateElementRequest( elementType );
req.setContainer(hostElement);
req.setEditingDomain(host.getEditingDomain());

BusinessModel model = MdaFactory.eINSTANCE.createBusinessModel();
model.setFile(file);
model.setName(name);

req.setNewElement(model);
viewDescriptors = new ArrayList();
viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
new CreateElementRequestAdapter(req),
Node.class, null, editPart.getDiagramPreferencesHint()));
MyDropCommand dropCommand = new MyDropCommand(req, model);
Command command = createViewsAndArrangeCommand(dropRequest,
viewDescriptors);
Command plop = new ICommandProxy(dropCommand).chain(command);
return plop;
}

With MyDropCommand.doDefaultElementCreation() returning my previous
created model EObject from DiagramDragDropEditPolicy.getDropFileCommand()

When testing I get a NPE at
org.eclipse.gef.editpolicies.ConstrainedLayoutEditPolicy.get ConstraintFor(ConstrainedLayoutEditPolicy.java:204)
cause by
org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.getDropObjectsCommand()
which call createViewsAndArrangeCommand()

I don't understand why.


Currently I used another mean, I used two first tips from
http://wiki.eclipse.org/index.php/GMF_Tips

and in my DiagramDragDropEditPolicy.getDropObjectsCommand() I have used
GMF tips (see attached source file).

When testing I have :

IllegalStateException: Cannot activate read/write transaction in
read-only transaction context

see attached .log

Thanks.

Igor Klinchin a écrit :
> Hi Esteban,
>
> On Tue, 14 Apr 2009 11:10:52 +0200, Esteban DUGUEPEROUX wrote:
>
>> Hi Igor,
>>
>> Thanks for you help, now I can create new elements(View with
>> corresponding model element : CreateViewAndElementRequest)
>> My code is similar to http://wiki.eclipse.org/index.php/GMF_Tips (first
>> tip).
>> But when I dropped a file to my diagram I would like to initialize my
>> new created element with property values according to my dropped file. I
>> could chain my first Command resulting of my CreateViewAndElementRequest
>> with a second command from a SetRequest but constructor of SetRequest
>> need the model element to change property then How to fetch created
>> element from my CreateViewAndElementRequest?
>
> I think that you need to create your own command (CreateElementCommand)
> based on the CreateElementRequest (and create this CreateElementRequest
> before it also). The command should build the new object and in its
> doDefaultElementCreation method add the object to the model. It could be
> done in DiagramDragDropEditPolicy like this:
>
> IGraphicalEditPart host = (IGraphicalEditPart) getHost();
> EObject hostElement = host.resolveSemanticElement();
>
> (...)
>
> CreateElementRequest req = new CreateElementRequest( elementType );
> req.setContainmentFeature(...);
> req.setContainer(hostElement);
> req.setEditingDomain(host.getEditingDomain());
> req.setNewElement(<... new object ...>);
>
> (...)
>
> ArrayList viewDescriptors = new ArrayList();
> viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
> <... new object ...>,
> Node.class, null, preferencesHint));
>
> MyDropTypeCommand dropCommand = new MyDropCommand(req);
> Command command = createViewsAndArrangeCommand(request, viewDescriptors);
> return new ICommandProxy(dropCommand).chain( command );
>
> It seems to me that there are many ways to do it and I am not sure that I
> have the most efficient one. It was kind of a solution that worked for me.
>
>> Also in GMF API, we can see two package with request :
>>
>> - org.eclipse.gmf.runtime.emf.type.core.requests
>> - org.eclipse.gmf.runtime.diagram.ui.requests
>>
>> EditPart.getCommand(Request) or in
>> DiagramDragDropEditPolicy.getCommand(Request) seems to accept only
>> requests from second package then What are requests from first package?
>
> The first one is used in the other command that you will need to implement
> extending CreateElementCommand in order to construct and add completely
> new object to the diagram. Here is a constructor for such command that you
> will need to call to initialize this command:
>
> public CreateElementCommand(CreateElementRequest request);
>
> This request is from org.eclipse.gmf.runtime.emf.type.core.requests;
>
> Basically request in DiagramDragDropEditPolicy.getDropObjectsCommand is
> from *.diagram.ui.requests. CreateElementRequest for your own command that
> will build the object is from *.runtime.emf.type.core.requests.
>
>
>
>> CreateViewAndElementRequest belongs to first package while SetRequest
>> belongs to second.
>> But to solve this, we can find in
>> org.eclipse.gmf.runtime.emf.type.core.commands package a SetValueCommand
>> which accept a SetRequest in constructor and with ICommandProxy we can
>> wrap the SetValueCommand to a org.eclipse.gef.commands.Command.
>>
>> This last think is correct?
>
> I think that we are talking about similar things.
>
>>
>> Also besides to DnD file, I would like to DnD EObject from a View to my
>> diagram, principe seem similar but instead of use SetRequest and
>> SetValueCommand I could use MoveRequest and MoveElementsCommand, correct?
>
> I think that MoveRequest and MoveElementCommand are about moving objects
> inside a diagram. It is like changing coordinates of a figure on the
> diagram. I might be wrong in this.
>
>> But in my DiagramDragDropEditPolicy, I call
>> DiagramDragDropEditPolicy.getHostObject() method to fetch model element
>> to pass my MoveRequest constructor but getHostObject() return null.
>> Why this return null in my EditPolicy?
>
> It is interesting that I also failed to use MoveElementsCommand with
> similar problems but I was sure that it is used to move figures inside a
> diagram. In this sence I explained it in the way that I could not move the
> figure in DiagramDragDropEditPolicy becuase it does not exist yet. It will
> be added to the diagram after my command that I construct here (from newly
> constructed request) will add it to the model and
> createViewsAndArrangeCommand will create a figure on the diagram. I tried
> to chain this MoveElementsCommand but with no success.
>
> I am sorry that I reply that late, I need to check old posts more often. I
> hope this discussion will help you to understand better the situation
> inside d&d. I missed such discussions while I was implementing my d&d and
> messsage from Alex helped me a lot to dig to the right place.
>
> Thank you,
> Igor
>
>
>> Igor Klinchin a écrit :
>>> Hi Esteban,
>>>
>>> I have getObjectsBeingDropped() method overriden in my
>>> DiagramDropTargetListener. Here I get
>>>
>>> ISelection selection = LocalSelectionTransfer.getTransfer().getSelection();
>>>
>>> then I check whether all objects are valid (I have objects that could be
>>> dropped on the diagram and others that could be not) and return
>>> ((IStructuredSelection) selection).toList();
>>>
>>> createTargetRequest() just return super.createTargetRequest();
>>>
>>> I also have DiagramDragDropEditPolicy with overridden
>>> getDropCommand(ChangeBoundsRequest request). Here I retrieve objects from
>>> DropObjectsRequest and make a CompoundCommand with a Command for each of
>>> the objects from there. Each command (for individual object) builds new
>>> object to be dropped (in my case I build totally new object since I dnd
>>> unrelated stuff like file from file system or object from different model
>>> - you may need to just copy the original object or use it as it is),
>>> create a command that will insert this object into the model and builds a
>>> composite command like this:
>>>
>>> CreateElementRequest req = new CreateElementRequest( elementType );
>>> MyDropCommand dropCommand = new MyDropCommand(req);
>>> ArrayList viewDescriptors = new ArrayList();
>>> viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
>>> new EObjectAdapter(MyNewObject),
>>> Node.class, null, preferencesHint));
>>>
>>> Command command = createViewsAndArrangeCommand(dropRequest,
>>> viewDescriptors);
>>> if( command != null ) {
>>> return new ICommandProxy(dropCommand).chain( command );
>>> }
>>>
>>> If you already have your object in you model (like you dnd from view that
>>> displays the same model so that editor already has this object) you may
>>> want to return command; only - no object needs to be inserted into the
>>> diagram. Otherwise, return command; will insert an object to the diagram
>>> but not in model.
>>>
>>> You can debug this piece so that
>>> DiagramDragDropEditPolicy.getDropCommand() should return not null command
>>> and viewDescriptors should contain a descriptor of some valid object from
>>> the model.
>>>
>>> I do no know whether you can leave default implementation of
>>> DiagramDragDropEditPolicy. It seems to me that you can in case you dnd
>>> objects of the same model. I have different situation, I dnd objects
>>> unrelated to the model so I had to replace the way how model objects are
>>> constructed. In any case, I think, you should install
>>> DiagramDragDropEditPolicy into your Diagram implementation. Also it might
>>> be that the problem is with DiagramDropTargetListener.
>>>
>>> Igor
>>>
>>> On Wed, 08 Apr 2009 17:06:04 +0200, Esteban DUGUEPEROUX wrote:
>>>
>>>> Hi Igor,
>>>>
>>>> I want to have same feature but from a view. Indeed I want DnD EObject
>>>> object from one view to my GMF editor I have setted a
>>>> DiagramDropTargetListener on my DiagramDocumentEditor. This
>>>> DropTargetListener have a createTargetRequest() creating a
>>>> DropObjectsRequest. By default createViewsAndArrangeCommand method is
>>>> called in DiagramDragDropEditPolicy then not needed to create a custom
>>>> DiagramDragDropEditPolicy. Do you really need a custom
>>>> DiagramDragDropEditPolicy? Do you do a particular action in handleDrop
>>>> of your DiagramDropTargetListener ?
>>>>
>>>> Can you give me some sample code?
>>>>
>>>> Thanks.
>>>>
>>>> Igor Klinchin a écrit :
>>>>> Hi Alex,
>>>>>
>>>>> Thank you very much for your suggestion. It helped a lot. After I started
>>>>> to build my command with createViewsAndArrangeCommand method my
>>>>> CREATION_ROLE policy installed for Diagram model element started to
>>>>> receive calls for getCommand method where I can get exact mouse location
>>>>> in right coordinates. I apply these coordinates in getCreateCommand of the
>>>>> same policy where location is always (-1, -1).
>>>>>
>>>>> I still do not understand why location gets broken in getCreateCommand but
>>>>> at least now I have a way to set correct location. When I create new
>>>>> element by picking a tool from palette the location is correct here.
>>>>> Bottom line is that my drag and drops create object right under the mouse
>>>>> cursor.
>>>>>
>>>>> Igor
>>>>>
>>>>> On Tue, 31 Mar 2009 11:05:33 +0000, Alex Shatalin wrote:
>>>>>
>>>>>> Hello Igor,
>>>>>>
>>>>>> Try calling org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.createViewsAndArrangeCommand()
>>>>>> - at least this method is called by GMf-generated code handling shortcuts
>>>>>> creation on D&D from ProjectExplorer and it looks like an element will be
>>>>>> created just below the mouse.
>>>>>>
>>>>>> -----------------
>>>>>> Alex Shatalin
>


--------------070903030304010706070009
Content-Type: text/plain;
name="TransfoProjectDiagramDragDropEditPolicy.java"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="TransfoProjectDiagramDragDropEditPolicy.java"

cGFja2FnZSBtZGEuY3VzdG9tLmVkaXRwb2xpY2llczsNCg0KaW1wb3J0IGph dmEuaW8uRmls
ZTsNCmltcG9ydCBqYXZhLm5ldC5VUkk7DQppbXBvcnQgamF2YS51dGlsLkFy cmF5TGlzdDsN
CmltcG9ydCBqYXZhLnV0aWwuQ29sbGVjdGlvbjsNCmltcG9ydCBqYXZhLnV0 aWwuTGlzdDsN
Cg0KaW1wb3J0IG1kYS5NZGFGYWN0b3J5Ow0KaW1wb3J0IG1kYS5NZGFQYWNr YWdlOw0KaW1w
b3J0IG1kYS5Nb2RlbDsNCmltcG9ydCBtZGEuY3VzdG9tLmNvbW1hbmRzLkRy b3BUcmFuc2Zv
UHJvamVjdENvbW1hbmQ7DQppbXBvcnQgbWRhLmRpYWdyYW0uZWRpdC5wYXJ0 cy5NREFQcm9q
ZWN0RWRpdFBhcnQ7DQppbXBvcnQgbWRhLmRpYWdyYW0uZWRpdC5wYXJ0cy5N b2RlbEVkaXRQ
YXJ0Ow0KaW1wb3J0IG1kYS5kaWFncmFtLnBhcnQuTWRhVmlzdWFsSURSZWdp c3RyeTsNCmlt
cG9ydCBtZGEuZGlhZ3JhbS5wcm92aWRlcnMuTWRhRWxlbWVudFR5cGVzOw0K DQppbXBvcnQg
b3JnLmVjbGlwc2UuY29yZS5ydW50aW1lLklBZGFwdGFibGU7DQppbXBvcnQg b3JnLmVjbGlw
c2UuZW1mLmVjb3JlLkVPYmplY3Q7DQppbXBvcnQgb3JnLmVjbGlwc2UuZ2Vm LmNvbW1hbmRz
LkNvbW1hbmQ7DQppbXBvcnQgb3JnLmVjbGlwc2UuZ2VmLmNvbW1hbmRzLkNv bXBvdW5kQ29t
bWFuZDsNCmltcG9ydCBvcmcuZWNsaXBzZS5nZWYucmVxdWVzdHMuQ2hhbmdl Qm91bmRzUmVx
dWVzdDsNCmltcG9ydCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5jb21tb24u Y29yZS5jb21t
YW5kLklDb21tYW5kOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1l LmRpYWdyYW0u
Y29yZS5lZGl0aGVscGVycy5DcmVhdGVFbGVtZW50UmVxdWVzdEFkYXB0ZXI7 DQppbXBvcnQg
b3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51aS5jb21tYW5kcy5J Q29tbWFuZFBy
b3h5Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLmRpYWdyYW0u dWkuZWRpdHBv
bGljaWVzLkRpYWdyYW1EcmFnRHJvcEVkaXRQb2xpY3k7DQppbXBvcnQgb3Jn LmVjbGlwc2Uu
Z21mLnJ1bnRpbWUuZGlhZ3JhbS51aS5wYXJ0cy5EaWFncmFtQ29tbWFuZFN0 YWNrOw0KaW1w
b3J0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLmRpYWdyYW0udWkucmVxdWVz dHMuQ3JlYXRl
Vmlld0FuZEVsZW1lbnRSZXF1ZXN0Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmdt Zi5ydW50aW1l
LmRpYWdyYW0udWkucmVxdWVzdHMuQ3JlYXRlVmlld1JlcXVlc3Q7DQppbXBv cnQgb3JnLmVj
bGlwc2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51aS5yZXF1ZXN0cy5Ecm9wT2Jq ZWN0c1JlcXVl
c3Q7DQppbXBvcnQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51 aS5yZXF1ZXN0
cy5DcmVhdGVWaWV3QW5kRWxlbWVudFJlcXVlc3QuVmlld0FuZEVsZW1lbnRE ZXNjcmlwdG9y
Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLmRpYWdyYW0udWku cmVxdWVzdHMu
Q3JlYXRlVmlld1JlcXVlc3QuVmlld0Rlc2NyaXB0b3I7DQppbXBvcnQgb3Jn LmVjbGlwc2Uu
Z21mLnJ1bnRpbWUuZW1mLnR5cGUuY29yZS5JRWxlbWVudFR5cGU7DQppbXBv cnQgb3JnLmVj
bGlwc2UuZ21mLnJ1bnRpbWUuZW1mLnR5cGUuY29yZS5JSGludGVkVHlwZTsN CmltcG9ydCBv
cmcuZWNsaXBzZS5nbWYucnVudGltZS5lbWYudHlwZS5jb3JlLmNvbW1hbmRz Lk1vdmVFbGVt
ZW50c0NvbW1hbmQ7DQppbXBvcnQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUu ZW1mLnR5cGUu
Y29yZS5jb21tYW5kcy5TZXRWYWx1ZUNvbW1hbmQ7DQppbXBvcnQgb3JnLmVj bGlwc2UuZ21m
LnJ1bnRpbWUuZW1mLnR5cGUuY29yZS5yZXF1ZXN0cy5DcmVhdGVFbGVtZW50 UmVxdWVzdDsN
CmltcG9ydCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5lbWYudHlwZS5jb3Jl LnJlcXVlc3Rz
Lk1vdmVSZXF1ZXN0Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1l LmVtZi50eXBl
LmNvcmUucmVxdWVzdHMuU2V0UmVxdWVzdDsNCmltcG9ydCBvcmcuZWNsaXBz ZS5nbWYucnVu
dGltZS5ub3RhdGlvbi5Ob2RlOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmdtZi5y dW50aW1lLm5v
dGF0aW9uLlZpZXc7DQoNCnB1YmxpYyBjbGFzcyBUcmFuc2ZvUHJvamVjdERp YWdyYW1EcmFn
RHJvcEVkaXRQb2xpY3kgZXh0ZW5kcw0KCQkvKiBYWUxheW91dEVkaXRQb2xp Y3kgKi9EaWFn
cmFtRHJhZ0Ryb3BFZGl0UG9saWN5IHsNCg0KCXByaXZhdGUgTURBUHJvamVj dEVkaXRQYXJ0
IHByb2plY3RFZGl0UGFydDsNCg0KCXB1YmxpYyBUcmFuc2ZvUHJvamVjdERp YWdyYW1EcmFn
RHJvcEVkaXRQb2xpY3koDQoJCQlNREFQcm9qZWN0RWRpdFBhcnQgcHJvamVj dEVkaXRQYXJ0
KSB7DQoJCXRoaXMucHJvamVjdEVkaXRQYXJ0ID0gcHJvamVjdEVkaXRQYXJ0 Ow0KCX0NCg0K
CUBPdmVycmlkZQ0KCXByb3RlY3RlZCBDb21tYW5kIGdldERyb3BDb21tYW5k KENoYW5nZUJv
dW5kc1JlcXVlc3QgcmVxdWVzdCkgew0KCQlDb21tYW5kIGNtZCA9IHN1cGVy LmdldERyb3BD
b21tYW5kKHJlcXVlc3QpOw0KCQlyZXR1cm4gY21kOw0KCX0NCg0KCUBPdmVy cmlkZQ0KCXBy
b3RlY3RlZCBDb21tYW5kIGdldERyb3BFbGVtZW50Q29tbWFuZChFT2JqZWN0 IGVsZW1lbnQs
DQoJCQlEcm9wT2JqZWN0c1JlcXVlc3QgcmVxdWVzdCkgew0KCQlDb21tYW5k IGNtZCA9IHN1
cGVyLmdldERyb3BFbGVtZW50Q29tbWFuZChlbGVtZW50LCByZXF1ZXN0KTsN CgkJcmV0dXJu
IGNtZDsNCgl9DQoNCglAT3ZlcnJpZGUNCglwcm90ZWN0ZWQgQ29tbWFuZCBn ZXREcm9wRmls
ZUNvbW1hbmQoRHJvcE9iamVjdHNSZXF1ZXN0IGRyb3BSZXF1ZXN0KSB7DQoJ CUNvbW1hbmQg
Y21kID0gc3VwZXIuZ2V0RHJvcEZpbGVDb21tYW5kKGRyb3BSZXF1ZXN0KTsN CgkJcmV0dXJu
IGNtZDsNCgl9DQoNCglAU3VwcHJlc3NXYXJuaW5ncygidW5jaGVja2VkIikN CglAT3ZlcnJp
ZGUNCglwdWJsaWMgQ29tbWFuZCBnZXREcm9wT2JqZWN0c0NvbW1hbmQoRHJv cE9iamVjdHNS
ZXF1ZXN0IGRyb3BSZXF1ZXN0KSB7DQoJCS8vIHJldHVybiB0ZXN0SW5zZXJ0 KCk7DQoJCUNv
bXBvdW5kQ29tbWFuZCByZXQgPSBuZXcgQ29tcG91bmRDb21tYW5kKCk7DQoJ CUxpc3Q8Q3Jl
YXRlVmlld1JlcXVlc3QuVmlld0Rlc2NyaXB0b3I+IHZpZXdEZXNjcmlwdG9y cyA9IG5ldyBB
cnJheUxpc3Q8Q3JlYXRlVmlld1JlcXVlc3QuVmlld0Rlc2NyaXB0b3I+KCk7 DQoJCUxpc3Qg
b2JqZWN0cyA9IGRyb3BSZXF1ZXN0LmdldE9iamVjdHMoKTsNCgkJTURBUHJv amVjdEVkaXRQ
YXJ0IGVkaXRQYXJ0ID0gKE1EQVByb2plY3RFZGl0UGFydCkgZ2V0SG9zdCgp Ow0KCQlJRWxl
bWVudFR5cGUgdHlwZSA9IE1kYUVsZW1lbnRUeXBlcy5Nb2RlbF8xMDA0Ow0K Ly8JCVZpZXdB
bmRFbGVtZW50RGVzY3JpcHRvciB2aWV3RGVzY3JpcHRvciA9IG5ldyBWaWV3 QW5kRWxlbWVu
dERlc2NyaXB0b3IoDQovLwkJCQluZXcgQ3JlYXRlRWxlbWVudFJlcXVlc3RB ZGFwdGVyKG5l
dyBDcmVhdGVFbGVtZW50UmVxdWVzdCh0eXBlKSksDQovLwkJCQlOb2RlLmNs YXNzLCAoKElI
aW50ZWRUeXBlKSB0eXBlKS5nZXRTZW1hbnRpY0hpbnQoKSwgZWRpdFBhcnQN Ci8vCQkJCQkJ
LmdldERpYWdyYW1QcmVmZXJlbmNlc0hpbnQoKSk7DQoNCgkJZm9yIChpbnQg aSA9IDA7IGkg
PCBvYmplY3RzLnNpemUoKTsgaSsrKSB7DQoJCQlPYmplY3QgbmV4dE9iamVj dCA9IG9iamVj
dHMuZ2V0KGkpOw0KCQkJQ29tbWFuZCBjbWQgPSBudWxsOw0KCQkJaWYgKG5l eHRPYmplY3Qg
aW5zdGFuY2VvZiBTdHJpbmcpIHsNCgkJCQlTdHJpbmcgZmlsZU5hbWUgPSAo U3RyaW5nKSBu
ZXh0T2JqZWN0Ow0KCQkJCUZpbGUgZmlsZSA9IG5ldyBGaWxlKGZpbGVOYW1l KTsNCgkJCQlT
dHJpbmcgbmFtZSA9IGZpbGUuZ2V0TmFtZSgpOw0KDQovLwkJCQlDcmVhdGVW aWV3QW5kRWxl
bWVudFJlcXVlc3QgcmVxID0gbmV3IENyZWF0ZVZpZXdBbmRFbGVtZW50UmVx dWVzdCgNCi8v
CQkJCQkJdmlld0Rlc2NyaXB0b3IpOw0KLy8JCQkJQ29tbWFuZCBjb21tYW5k ID0gbnVsbDsN
Ci8vCQkJCWNvbW1hbmQgPSBlZGl0UGFydC5nZXRDb21tYW5kKHJlcSk7DQoN CgkJCQlTdHJp
bmcgYnVzaW5lc3NTZW1hbnRpY0hpbnQgPSBNZGFWaXN1YWxJRFJlZ2lzdHJ5 LmdldFR5cGUo
TW9kZWxFZGl0UGFydC5WSVNVQUxfSUQpOw0KCQkJCUlFbGVtZW50VHlwZSBl bGVtZW50VHlw
ZSA9IE1kYUVsZW1lbnRUeXBlcy5Nb2RlbF8xMDA0Ow0KDQoJCQkJVmlld0Fu ZEVsZW1lbnRE
ZXNjcmlwdG9yIHZpZXdEZXNjcmlwdG9yID0gbmV3IFZpZXdBbmRFbGVtZW50 RGVzY3JpcHRv
cihuZXcgQ3JlYXRlRWxlbWVudFJlcXVlc3RBZGFwdGVyKA0KCQkJCQkJbmV3 IENyZWF0ZUVs
ZW1lbnRSZXF1ZXN0KGVsZW1lbnRUeXBlKSksIE5vZGUuY2xhc3MsICgoSUhp bnRlZFR5cGUp
IGVsZW1lbnRUeXBlKQ0KCQkJCQkJLmdldFNlbWFudGljSGludCgpLCBlZGl0 UGFydC5nZXRE
aWFncmFtUHJlZmVyZW5jZXNIaW50KCkpOw0KDQoJCQkJQ3JlYXRlVmlld0Fu ZEVsZW1lbnRS
ZXF1ZXN0IHJlcSA9IG5ldyBDcmVhdGVWaWV3QW5kRWxlbWVudFJlcXVlc3Qo dmlld0Rlc2Ny
aXB0b3IpOw0KCQkJCUNvbW1hbmQgY3JlYXRlQnVzaW5lc3NDbWQgPSBlZGl0 UGFydC5nZXRD
b21tYW5kKHJlcSk7DQoNCgkJCQllZGl0UGFydC5nZXREaWFncmFtRWRpdERv bWFpbigpLmdl
dERpYWdyYW1Db21tYW5kU3RhY2soKS5leGVjdXRlKGNyZWF0ZUJ1c2luZXNz Q21kKTsNCgkJ
CQlDb2xsZWN0aW9uIHJlc3VsdCA9IERpYWdyYW1Db21tYW5kU3RhY2suZ2V0 UmV0dXJuVmFs
dWVzKGNyZWF0ZUJ1c2luZXNzQ21kKTsNCgkJCQlTeXN0ZW0ub3V0LnByaW50 bG4oInJlc3Vs
dCA6ICIgKyByZXN1bHQpOw0KCQkJCWZvciAoT2JqZWN0IHJlcyA6IHJlc3Vs dCkgew0KCQkJ
CQlpZiAocmVzIGluc3RhbmNlb2YgSUFkYXB0YWJsZSkgew0KCQkJCQkJSUFk YXB0YWJsZSBh
ZGFwdGVyID0gKElBZGFwdGFibGUpIHJlczsNCgkJCQkJCVZpZXcgdmlldyA9 IChWaWV3KSBh
ZGFwdGVyLmdldEFkYXB0ZXIoVmlldy5jbGFzcyk7DQoJCQkJCQlpZiAodmll dyAhPSBudWxs
KSB7DQoJCQkJCQkJTW9kZWwgbmV3TW9kZWwgPSAoTW9kZWwpIHZpZXcuZ2V0 RWxlbWVudCgp
Ow0KCQkJCQkJCVVSSSB1cmkgPSBmaWxlLnRvVVJJKCk7DQoJCQkJCQkJU2V0 UmVxdWVzdCBy
ZXFTZXROYW1lID0gbmV3IFNldFJlcXVlc3QoZWRpdFBhcnQuZ2V0RWRpdGlu Z0RvbWFpbigp
LCBuZXdNb2RlbCwNCgkJCQkJCQkJCU1kYVBhY2thZ2UuZUlOU1RBTkNFLmdl dE1vZGVsX05h
bWUoKSwgbmFtZSk7DQoJCQkJCQkJU2V0UmVxdWVzdCByZXFTZXRVUkkgPSBu ZXcgU2V0UmVx
dWVzdChlZGl0UGFydC5nZXRFZGl0aW5nRG9tYWluKCksIG5ld01vZGVsLA0K CQkJCQkJCQkJ
TWRhUGFja2FnZS5lSU5TVEFOQ0UuZ2V0TW9kZWxfRmlsZSgpLCB1cmkpOw0K CQkJCQkJCVNl
dFZhbHVlQ29tbWFuZCBzZXROYW1lT3BlcmF0aW9uID0gbmV3IFNldFZhbHVl Q29tbWFuZChy
ZXFTZXROYW1lKTsNCgkJCQkJCQlTZXRWYWx1ZUNvbW1hbmQgc2V0VVJJT3Bl cmF0aW9uID0g
bmV3IFNldFZhbHVlQ29tbWFuZChyZXFTZXRVUkkpOw0KCQkJCQkJCWVkaXRQ YXJ0LmdldERp
YWdyYW1FZGl0RG9tYWluKCkuZ2V0RGlhZ3JhbUNvbW1hbmRTdGFjaygpLmV4 ZWN1dGUoDQoJ
CQkJCQkJCQluZXcgSUNvbW1hbmRQcm94eShzZXROYW1lT3BlcmF0aW9uKSk7 DQoJCQkJCQkJ
ZWRpdFBhcnQuZ2V0RGlhZ3JhbUVkaXREb21haW4oKS5nZXREaWFncmFtQ29t bWFuZFN0YWNr
KCkuZXhlY3V0ZSgNCgkJCQkJCQkJCW5ldyBJQ29tbWFuZFByb3h5KHNldFVS SU9wZXJhdGlv
bikpOw0KCQkJCQkJfQ0KCQkJCQl9DQoJCQkJfQ0KCQkJCWNtZCA9IGNyZWF0 ZUJ1c2luZXNz
Q21kOw0KCQkJfSBlbHNlIGlmIChuZXh0T2JqZWN0IGluc3RhbmNlb2YgRU9i amVjdCkgew0K
CQkJCS8vIFZpZXdEZXNjcmlwdG9yIGRlc2NyaXB0b3IgPSBuZXcgVmlld0Rl c2NyaXB0b3Io
bmV3DQoJCQkJLy8gRU9iamVjdEFkYXB0ZXIoKEVPYmplY3QpIG5leHRPYmpl Y3QpLA0KCQkJ
CS8vIE5vZGUuY2xhc3MsIG51bGwsDQoJCQkJLy8gcHJvamVjdEVkaXRQYXJ0 LmdldERpYWdy
YW1QcmVmZXJlbmNlc0hpbnQoKSk7DQoJCQkJLy8gQ3JlYXRlVmlld1JlcXVl c3QgcmVxID0g
bmV3IENyZWF0ZVZpZXdSZXF1ZXN0KGRlc2NyaXB0b3IpOw0KCQkJCUVPYmpl Y3QgdGFyZ2V0
T2JqZWN0ID0gZ2V0SG9zdE9iamVjdCgpOw0KCQkJCVN5c3RlbS5vdXQucHJp bnRsbigidGFy
Z2V0T2JqZWN0IDogIiArIHRhcmdldE9iamVjdCk7DQoJCQkJRU9iamVjdCBl bGVtZW50VG9N
b3ZlID0gKEVPYmplY3QpIG5leHRPYmplY3Q7DQoJCQkJTW92ZVJlcXVlc3Qg bW92ZVJlcXVl
c3QgPSBuZXcgTW92ZVJlcXVlc3QodGFyZ2V0T2JqZWN0LA0KCQkJCQkJTWRh RmFjdG9yeS5l
SU5TVEFOQ0UuZ2V0TWRhUGFja2FnZSgpDQoJCQkJCQkJCS5nZXRNREFQcm9q ZWN0X1RyYW5z
Zm9ybWF0aW9ucygpLCBlbGVtZW50VG9Nb3ZlKTsNCgkJCQlNb3ZlRWxlbWVu dHNDb21tYW5k
IG1vdmVFbGVtZW50c0NvbW1hbmQgPSBuZXcgTW92ZUVsZW1lbnRzQ29tbWFu ZCgNCgkJCQkJ
CW1vdmVSZXF1ZXN0KTsNCgkJCQlJQ29tbWFuZFByb3h5IGNvbW1hbmRQcm94 eSA9IG5ldyBJ
Q29tbWFuZFByb3h5KA0KCQkJCQkJbW92ZUVsZW1lbnRzQ29tbWFuZCk7DQoJ CQkJY21kID0g
Y29tbWFuZFByb3h5Ow0KDQoJCQl9IGVsc2Ugew0KCQkJCWNvbnRpbnVlOw0K CQkJfQ0KCQkJ
cmV0LmFkZChjbWQpOw0KCQkJU3lzdGVtLm91dC5wcmludGxuKCJjbWQgOiAi ICsgY21kKTsN
CgkJfQ0KDQoJCXJldHVybiByZXQ7DQoJfQ0KDQp9DQo=
--------------070903030304010706070009
Content-Type: text/plain;
name=".log"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename=".log"

DQohRU5UUlkgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51aSA0 IDQgMjAwOS0w
NC0yNyAxODoxNzozOC4wMTUNCiFNRVNTQUdFIGV4ZWN1dGUNCiFTVEFDSyAw DQpvcmcuZWNs
aXBzZS5jb3JlLmNvbW1hbmRzLkV4ZWN1dGlvbkV4Y2VwdGlvbjogV2hpbGUg ZXhlY3V0aW5n
IHRoZSBvcGVyYXRpb24sIGFuIGV4Y2VwdGlvbiBvY2N1cnJlZA0KCWF0IG9y Zy5lY2xpcHNl
LmNvcmUuY29tbWFuZHMub3BlcmF0aW9ucy5EZWZhdWx0T3BlcmF0aW9uSGlz dG9yeS5leGVj
dXRlKERlZmF1bHRPcGVyYXRpb25IaXN0b3J5LmphdmE6NTE5KQ0KCWF0IG9y Zy5lY2xpcHNl
LmdtZi5ydW50aW1lLmRpYWdyYW0udWkucGFydHMuRGlhZ3JhbUNvbW1hbmRT dGFjay5leGVj
dXRlKERpYWdyYW1Db21tYW5kU3RhY2suamF2YToyMDUpDQoJYXQgb3JnLmVj bGlwc2UuZ21m
LnJ1bnRpbWUuZGlhZ3JhbS51aS5wYXJ0cy5EaWFncmFtQ29tbWFuZFN0YWNr LmV4ZWN1dGUo
RGlhZ3JhbUNvbW1hbmRTdGFjay5qYXZhOjE2OCkNCglhdCBvcmcuZWNsaXBz ZS5nbWYucnVu
dGltZS5kaWFncmFtLnVpLnBhcnRzLkRpYWdyYW1Db21tYW5kU3RhY2suZXhl Y3V0ZShEaWFn
cmFtQ29tbWFuZFN0YWNrLmphdmE6MTU1KQ0KCWF0IG1kYS5jdXN0b20uZWRp dHBvbGljaWVz
LlRyYW5zZm9Qcm9qZWN0RGlhZ3JhbURyYWdEcm9wRWRpdFBvbGljeS5nZXRE cm9wT2JqZWN0
c0NvbW1hbmQoVHJhbnNmb1Byb2plY3REaWFncmFtRHJhZ0Ryb3BFZGl0UG9s aWN5LmphdmE6
MTA5KQ0KCWF0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLmRpYWdyYW0udWku ZWRpdHBvbGlj
aWVzLkRyYWdEcm9wRWRpdFBvbGljeS5nZXRDb21tYW5kKERyYWdEcm9wRWRp dFBvbGljeS5q
YXZhOjgwKQ0KCWF0IG9yZy5lY2xpcHNlLmdlZi5lZGl0cGFydHMuQWJzdHJh Y3RFZGl0UGFy
dC5nZXRDb21tYW5kKEFic3RyYWN0RWRpdFBhcnQuamF2YTo0NzMpDQoJYXQg b3JnLmVjbGlw
c2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51aS5lZGl0cGFydHMuR3JhcGhpY2Fs RWRpdFBhcnQu
YWNjZXNzJDEoR3JhcGhpY2FsRWRpdFBhcnQuamF2YToxKQ0KCWF0IG9yZy5l Y2xpcHNlLmdt
Zi5ydW50aW1lLmRpYWdyYW0udWkuZWRpdHBhcnRzLkdyYXBoaWNhbEVkaXRQ YXJ0JDEucnVu
KEdyYXBoaWNhbEVkaXRQYXJ0LmphdmE6NDY2KQ0KCWF0IG9yZy5lY2xpcHNl LmVtZi50cmFu
c2FjdGlvbi5pbXBsLlRyYW5zYWN0aW9uYWxFZGl0aW5nRG9tYWluSW1wbC5y dW5FeGNsdXNp
dmUoVHJhbnNhY3Rpb25hbEVkaXRpbmdEb21haW5JbXBsLmphdmE6Mjg5KQ0K CWF0IG9yZy5l
Y2xpcHNlLmdtZi5ydW50aW1lLmRpYWdyYW0udWkuZWRpdHBhcnRzLkdyYXBo aWNhbEVkaXRQ
YXJ0LmdldENvbW1hbmQoR3JhcGhpY2FsRWRpdFBhcnQuamF2YTo0NjEpDQoJ YXQgb3JnLmVj
bGlwc2UuZ2VmLmRuZC5BYnN0cmFjdFRyYW5zZmVyRHJvcFRhcmdldExpc3Rl bmVyLmdldENv
bW1hbmQoQWJzdHJhY3RUcmFuc2ZlckRyb3BUYXJnZXRMaXN0ZW5lci5qYXZh OjIwMSkNCglh
dCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5kaWFncmFtLnVpLnBhcnRzLkRp YWdyYW1Ecm9w
VGFyZ2V0TGlzdGVuZXIuaXNFbmFibGVkKERpYWdyYW1Ecm9wVGFyZ2V0TGlz dGVuZXIuamF2
YToyMjMpDQoJYXQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51 aS5pbnRlcm5h
bC5wYXJ0cy5JbWFnZUZpbGVEcm9wVGFyZ2V0TGlzdGVuZXIuaXNFbmFibGVk KEltYWdlRmls
ZURyb3BUYXJnZXRMaXN0ZW5lci5qYXZhOjEwMSkNCglhdCBvcmcuZWNsaXBz ZS5qZmFjZS51
dGlsLkRlbGVnYXRpbmdEcm9wQWRhcHRlci51cGRhdGVDdXJyZW50TGlzdGVu ZXIoRGVsZWdh
dGluZ0Ryb3BBZGFwdGVyLmphdmE6MzY1KQ0KCWF0IG9yZy5lY2xpcHNlLmpm YWNlLnV0aWwu
RGVsZWdhdGluZ0Ryb3BBZGFwdGVyLmRyYWdFbnRlcihEZWxlZ2F0aW5nRHJv cEFkYXB0ZXIu
amF2YToxMjgpDQoJYXQgb3JnLmVjbGlwc2Uuc3d0LmRuZC5ETkRMaXN0ZW5l ci5oYW5kbGVF
dmVudChETkRMaXN0ZW5lci5qYXZhOjYwKQ0KCWF0IG9yZy5lY2xpcHNlLnN3 dC53aWRnZXRz
LkV2ZW50VGFibGUuc2VuZEV2ZW50KEV2ZW50VGFibGUuamF2YTo4NCkNCglh dCBvcmcuZWNs
aXBzZS5zd3Qud2lkZ2V0cy5XaWRnZXQuc2VuZEV2ZW50KFdpZGdldC5qYXZh OjEwMDMpDQoJ
YXQgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuV2lkZ2V0LnNlbmRFdmVudChX aWRnZXQuamF2
YToxMDI3KQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLldpZGdldC5z ZW5kRXZlbnQo
V2lkZ2V0LmphdmE6MTAxMikNCglhdCBvcmcuZWNsaXBzZS5zd3Qud2lkZ2V0 cy5XaWRnZXQu
bm90aWZ5TGlzdGVuZXJzKFdpZGdldC5qYXZhOjc3MCkNCglhdCBvcmcuZWNs aXBzZS5zd3Qu
ZG5kLkRyb3BUYXJnZXQuRHJhZ0VudGVyKERyb3BUYXJnZXQuamF2YToyOTYp DQoJYXQgb3Jn
LmVjbGlwc2Uuc3d0LmRuZC5Ecm9wVGFyZ2V0JDMubWV0aG9kMyhEcm9wVGFy Z2V0LmphdmE6
MjQyKQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC5pbnRlcm5hbC5vbGUud2luMzIu Q09NT2JqZWN0
LmNhbGxiYWNrMyhDT01PYmplY3QuamF2YTo5MikNCglhdCBvcmcuZWNsaXBz ZS5zd3QuaW50
ZXJuYWwub2xlLndpbjMyLkNPTS5Eb0RyYWdEcm9wKE5hdGl2ZSBNZXRob2Qp DQoJYXQgb3Jn
LmVjbGlwc2Uuc3d0LmRuZC5EcmFnU291cmNlLmRyYWcoRHJhZ1NvdXJjZS5q YXZhOjM2MikN
CglhdCBvcmcuZWNsaXBzZS5zd3QuZG5kLkRyYWdTb3VyY2UuYWNjZXNzJDAo RHJhZ1NvdXJj
ZS5qYXZhOjI4OCkNCglhdCBvcmcuZWNsaXBzZS5zd3QuZG5kLkRyYWdTb3Vy Y2UkMS5oYW5k
bGVFdmVudChEcmFnU291cmNlLmphdmE6MTcxKQ0KCWF0IG9yZy5lY2xpcHNl LnN3dC53aWRn
ZXRzLkV2ZW50VGFibGUuc2VuZEV2ZW50KEV2ZW50VGFibGUuamF2YTo4NCkN CglhdCBvcmcu
ZWNsaXBzZS5zd3Qud2lkZ2V0cy5XaWRnZXQuc2VuZEV2ZW50KFdpZGdldC5q YXZhOjEwMDMp
DQoJYXQgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuRGlzcGxheS5ydW5EZWZl cnJlZEV2ZW50
cyhEaXNwbGF5LmphdmE6MzgyMykNCglhdCBvcmcuZWNsaXBzZS5zd3Qud2lk Z2V0cy5EaXNw
bGF5LnJlYWRBbmREaXNwYXRjaChEaXNwbGF5LmphdmE6MzQyMikNCglhdCBv cmcuZWNsaXBz
ZS51aS5pbnRlcm5hbC5Xb3JrYmVuY2gucnVuRXZlbnRMb29wKFdvcmtiZW5j aC5qYXZhOjIz
ODQpDQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuV29ya2JlbmNoLnJ1 blVJKFdvcmti
ZW5jaC5qYXZhOjIzNDgpDQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwu V29ya2JlbmNo
LmFjY2VzcyQ0KFdvcmtiZW5jaC5qYXZhOjIyMDApDQoJYXQgb3JnLmVjbGlw c2UudWkuaW50
ZXJuYWwuV29ya2JlbmNoJDUucnVuKFdvcmtiZW5jaC5qYXZhOjQ5NSkNCglh dCBvcmcuZWNs
aXBzZS5jb3JlLmRhdGFiaW5kaW5nLm9ic2VydmFibGUuUmVhbG0ucnVuV2l0 aERlZmF1bHQo
UmVhbG0uamF2YToyODgpDQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwu V29ya2JlbmNo
LmNyZWF0ZUFuZFJ1bldvcmtiZW5jaChXb3JrYmVuY2guamF2YTo0OTApDQoJ YXQgb3JnLmVj
bGlwc2UudWkuUGxhdGZvcm1VSS5jcmVhdGVBbmRSdW5Xb3JrYmVuY2goUGxh dGZvcm1VSS5q
YXZhOjE0OSkNCglhdCBvcmcuZWNsaXBzZS51aS5pbnRlcm5hbC5pZGUuYXBw bGljYXRpb24u
SURFQXBwbGljYXRpb24uc3RhcnQoSURFQXBwbGljYXRpb24uamF2YToxMTMp DQoJYXQgb3Jn
LmVjbGlwc2UuZXF1aW5veC5pbnRlcm5hbC5hcHAuRWNsaXBzZUFwcEhhbmRs ZS5ydW4oRWNs
aXBzZUFwcEhhbmRsZS5qYXZhOjE5MykNCglhdCBvcmcuZWNsaXBzZS5jb3Jl LnJ1bnRpbWUu
aW50ZXJuYWwuYWRhcHRvci5FY2xpcHNlQXBwTGF1bmNoZXIucnVuQXBwbGlj YXRpb24oRWNs
aXBzZUFwcExhdW5jaGVyLmphdmE6MTEwKQ0KCWF0IG9yZy5lY2xpcHNlLmNv cmUucnVudGlt
ZS5pbnRlcm5hbC5hZGFwdG9yLkVjbGlwc2VBcHBMYXVuY2hlci5zdGFydChF Y2xpcHNlQXBw
TGF1bmNoZXIuamF2YTo3OSkNCglhdCBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRp bWUuYWRhcHRv
ci5FY2xpcHNlU3RhcnRlci5ydW4oRWNsaXBzZVN0YXJ0ZXIuamF2YTozODYp DQoJYXQgb3Jn
LmVjbGlwc2UuY29yZS5ydW50aW1lLmFkYXB0b3IuRWNsaXBzZVN0YXJ0ZXIu cnVuKEVjbGlw
c2VTdGFydGVyLmphdmE6MTc5KQ0KCWF0IHN1bi5yZWZsZWN0Lk5hdGl2ZU1l dGhvZEFjY2Vz
c29ySW1wbC5pbnZva2UwKE5hdGl2ZSBNZXRob2QpDQoJYXQgc3VuLnJlZmxl Y3QuTmF0aXZl
TWV0aG9kQWNjZXNzb3JJbXBsLmludm9rZShOYXRpdmVNZXRob2RBY2Nlc3Nv ckltcGwuamF2
YTozOSkNCglhdCBzdW4ucmVmbGVjdC5EZWxlZ2F0aW5nTWV0aG9kQWNjZXNz b3JJbXBsLmlu
dm9rZShEZWxlZ2F0aW5nTWV0aG9kQWNjZXNzb3JJbXBsLmphdmE6MjUpDQoJ YXQgamF2YS5s
YW5nLnJlZmxlY3QuTWV0aG9kLmludm9rZShNZXRob2QuamF2YTo1ODUpDQoJ YXQgb3JnLmVj
bGlwc2UuZXF1aW5veC5sYXVuY2hlci5NYWluLmludm9rZUZyYW1ld29yayhN YWluLmphdmE6
NTQ5KQ0KCWF0IG9yZy5lY2xpcHNlLmVxdWlub3gubGF1bmNoZXIuTWFpbi5i YXNpY1J1bihN
YWluLmphdmE6NTA0KQ0KCWF0IG9yZy5lY2xpcHNlLmVxdWlub3gubGF1bmNo ZXIuTWFpbi5y
dW4oTWFpbi5qYXZhOjEyMzYpDQoJYXQgb3JnLmVjbGlwc2UuZXF1aW5veC5s YXVuY2hlci5N
YWluLm1haW4oTWFpbi5qYXZhOjEyMTIpDQpDYXVzZWQgYnk6IGphdmEubGFu Zy5JbGxlZ2Fs
U3RhdGVFeGNlcHRpb246IENhbm5vdCBhY3RpdmF0ZSByZWFkL3dyaXRlIHRy YW5zYWN0aW9u
IGluIHJlYWQtb25seSB0cmFuc2FjdGlvbiBjb250ZXh0DQoJYXQgb3JnLmVj bGlwc2UuZW1m
LnRyYW5zYWN0aW9uLmltcGwuVHJhbnNhY3Rpb25hbEVkaXRpbmdEb21haW5J bXBsLmFjcXVp
cmUoVHJhbnNhY3Rpb25hbEVkaXRpbmdEb21haW5JbXBsLmphdmE6NTM3KQ0K CWF0IG9yZy5l
Y2xpcHNlLmVtZi50cmFuc2FjdGlvbi5pbXBsLlRyYW5zYWN0aW9uYWxFZGl0 aW5nRG9tYWlu
SW1wbC5hY3RpdmF0ZShUcmFuc2FjdGlvbmFsRWRpdGluZ0RvbWFpbkltcGwu amF2YTo0Njkp
DQoJYXQgb3JnLmVjbGlwc2UuZW1mLnRyYW5zYWN0aW9uLmltcGwuVHJhbnNh Y3Rpb25JbXBs
LnN0YXJ0KFRyYW5zYWN0aW9uSW1wbC5qYXZhOjE4NCkNCglhdCBvcmcuZWNs aXBzZS5lbWYu
dHJhbnNhY3Rpb24uaW1wbC5UcmFuc2FjdGlvbmFsRWRpdGluZ0RvbWFpbklt cGwuc3RhcnRU
cmFuc2FjdGlvbihUcmFuc2FjdGlvbmFsRWRpdGluZ0RvbWFpbkltcGwuamF2 YTozODUpDQoJ
YXQgb3JnLmVjbGlwc2UuZW1mLndvcmtzcGFjZS5BYnN0cmFjdEVNRk9wZXJh dGlvbi5jcmVh
dGVUcmFuc2FjdGlvbihBYnN0cmFjdEVNRk9wZXJhdGlvbi5qYXZhOjU0MykN CglhdCBvcmcu
ZWNsaXBzZS5lbWYud29ya3NwYWNlLkFic3RyYWN0RU1GT3BlcmF0aW9uLmV4 ZWN1dGUoQWJz
dHJhY3RFTUZPcGVyYXRpb24uamF2YToxNjYpDQoJYXQgb3JnLmVjbGlwc2Uu Z21mLnJ1bnRp
bWUuZGlhZ3JhbS51aS5jb21tYW5kcy5TZW1hbnRpY0NyZWF0ZUNvbW1hbmQu ZG9FeGVjdXRl
V2l0aFJlc3VsdChTZW1hbnRpY0NyZWF0ZUNvbW1hbmQuamF2YTo3MSkNCglh dCBvcmcuZWNs
aXBzZS5nbWYucnVudGltZS5jb21tb24uY29yZS5jb21tYW5kLkFic3RyYWN0 Q29tbWFuZC5l
eGVjdXRlKEFic3RyYWN0Q29tbWFuZC5qYXZhOjEzNSkNCglhdCBvcmcuZWNs aXBzZS5nbWYu
cnVudGltZS5jb21tb24uY29yZS5jb21tYW5kLkNvbXBvc2l0ZUNvbW1hbmQu ZG9FeGVjdXRl
V2l0aFJlc3VsdChDb21wb3NpdGVDb21tYW5kLmphdmE6NDAzKQ0KCWF0IG9y Zy5lY2xpcHNl
LmdtZi5ydW50aW1lLmNvbW1vbi5jb3JlLmNvbW1hbmQuQWJzdHJhY3RDb21t YW5kLmV4ZWN1
dGUoQWJzdHJhY3RDb21tYW5kLmphdmE6MTM1KQ0KCWF0IG9yZy5lY2xpcHNl LmdtZi5ydW50
aW1lLmNvbW1vbi5jb3JlLmNvbW1hbmQuQ29tcG9zaXRlQ29tbWFuZC5kb0V4 ZWN1dGVXaXRo
UmVzdWx0KENvbXBvc2l0ZUNvbW1hbmQuamF2YTo0MDMpDQoJYXQgb3JnLmVj bGlwc2UuZ21m
LnJ1bnRpbWUuY29tbW9uLmNvcmUuY29tbWFuZC5BYnN0cmFjdENvbW1hbmQu ZXhlY3V0ZShB
YnN0cmFjdENvbW1hbmQuamF2YToxMzUpDQoJYXQgb3JnLmVjbGlwc2UuY29y ZS5jb21tYW5k
cy5vcGVyYXRpb25zLkRlZmF1bHRPcGVyYXRpb25IaXN0b3J5LmV4ZWN1dGUo RGVmYXVsdE9w
ZXJhdGlvbkhpc3RvcnkuamF2YTo1MTEpDQoJLi4uIDUzIG1vcmUNCg0KIUVO VFJZIG9yZy5l
Y2xpcHNlLmdtZi5ydW50aW1lLmRpYWdyYW0udWkgNCA0IDIwMDktMDQtMjcg MTg6MTc6Mzgu
MDMxDQohTUVTU0FHRSBleGVjdXRlDQohU1RBQ0sgMA0Kb3JnLmVjbGlwc2Uu Y29yZS5jb21t
YW5kcy5FeGVjdXRpb25FeGNlcHRpb246IFdoaWxlIGV4ZWN1dGluZyB0aGUg b3BlcmF0aW9u
LCBhbiBleGNlcHRpb24gb2NjdXJyZWQNCglhdCBvcmcuZWNsaXBzZS5jb3Jl LmNvbW1hbmRz
Lm9wZXJhdGlvbnMuRGVmYXVsdE9wZXJhdGlvbkhpc3RvcnkuZXhlY3V0ZShE ZWZhdWx0T3Bl
cmF0aW9uSGlzdG9yeS5qYXZhOjUxOSkNCglhdCBvcmcuZWNsaXBzZS5nbWYu cnVudGltZS5k
aWFncmFtLnVpLnBhcnRzLkRpYWdyYW1Db21tYW5kU3RhY2suZXhlY3V0ZShE aWFncmFtQ29t
bWFuZFN0YWNrLmphdmE6MjA1KQ0KCWF0IG9yZy5lY2xpcHNlLmdtZi5ydW50 aW1lLmRpYWdy
YW0udWkucGFydHMuRGlhZ3JhbUNvbW1hbmRTdGFjay5leGVjdXRlKERpYWdy YW1Db21tYW5k
U3RhY2suamF2YToxNjgpDQoJYXQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUu ZGlhZ3JhbS51
aS5wYXJ0cy5EaWFncmFtQ29tbWFuZFN0YWNrLmV4ZWN1dGUoRGlhZ3JhbUNv bW1hbmRTdGFj
ay5qYXZhOjE1NSkNCglhdCBtZGEuY3VzdG9tLmVkaXRwb2xpY2llcy5UcmFu c2ZvUHJvamVj
dERpYWdyYW1EcmFnRHJvcEVkaXRQb2xpY3kuZ2V0RHJvcE9iamVjdHNDb21t YW5kKFRyYW5z
Zm9Qcm9qZWN0RGlhZ3JhbURyYWdEcm9wRWRpdFBvbGljeS5qYXZhOjEwOSkN CglhdCBvcmcu
ZWNsaXBzZS5nbWYucnVudGltZS5kaWFncmFtLnVpLmVkaXRwb2xpY2llcy5E cmFnRHJvcEVk
aXRQb2xpY3kuZ2V0Q29tbWFuZChEcmFnRHJvcEVkaXRQb2xpY3kuamF2YTo4 MCkNCglhdCBv
cmcuZWNsaXBzZS5nZWYuZWRpdHBhcnRzLkFic3RyYWN0RWRpdFBhcnQuZ2V0 Q29tbWFuZChB
YnN0cmFjdEVkaXRQYXJ0LmphdmE6NDczKQ0KCWF0IG9yZy5lY2xpcHNlLmdt Zi5ydW50aW1l
LmRpYWdyYW0udWkuZWRpdHBhcnRzLkdyYXBoaWNhbEVkaXRQYXJ0LmFjY2Vz cyQxKEdyYXBo
aWNhbEVkaXRQYXJ0LmphdmE6MSkNCglhdCBvcmcuZWNsaXBzZS5nbWYucnVu dGltZS5kaWFn
cmFtLnVpLmVkaXRwYXJ0cy5HcmFwaGljYWxFZGl0UGFydCQxLnJ1bihHcmFw aGljYWxFZGl0
UGFydC5qYXZhOjQ2NikNCglhdCBvcmcuZWNsaXBzZS5lbWYudHJhbnNhY3Rp b24uaW1wbC5U
cmFuc2FjdGlvbmFsRWRpdGluZ0RvbWFpbkltcGwucnVuRXhjbHVzaXZlKFRy YW5zYWN0aW9u
YWxFZGl0aW5nRG9tYWluSW1wbC5qYXZhOjI4OSkNCglhdCBvcmcuZWNsaXBz ZS5nbWYucnVu
dGltZS5kaWFncmFtLnVpLmVkaXRwYXJ0cy5HcmFwaGljYWxFZGl0UGFydC5n ZXRDb21tYW5k
KEdyYXBoaWNhbEVkaXRQYXJ0LmphdmE6NDYxKQ0KCWF0IG9yZy5lY2xpcHNl LmdlZi5kbmQu
QWJzdHJhY3RUcmFuc2ZlckRyb3BUYXJnZXRMaXN0ZW5lci5nZXRDb21tYW5k KEFic3RyYWN0
VHJhbnNmZXJEcm9wVGFyZ2V0TGlzdGVuZXIuamF2YToyMDEpDQoJYXQgb3Jn LmVjbGlwc2Uu
Z21mLnJ1bnRpbWUuZGlhZ3JhbS51aS5wYXJ0cy5EaWFncmFtRHJvcFRhcmdl dExpc3RlbmVy
LmlzRW5hYmxlZChEaWFncmFtRHJvcFRhcmdldExpc3RlbmVyLmphdmE6MjIz KQ0KCWF0IG9y
Zy5lY2xpcHNlLmdtZi5ydW50aW1lLmRpYWdyYW0udWkuaW50ZXJuYWwucGFy dHMuSW1hZ2VG
aWxlRHJvcFRhcmdldExpc3RlbmVyLmlzRW5hYmxlZChJbWFnZUZpbGVEcm9w VGFyZ2V0TGlz
dGVuZXIuamF2YToxMDEpDQoJYXQgb3JnLmVjbGlwc2UuamZhY2UudXRpbC5E ZWxlZ2F0aW5n
RHJvcEFkYXB0ZXIudXBkYXRlQ3VycmVudExpc3RlbmVyKERlbGVnYXRpbmdE cm9wQWRhcHRl
ci5qYXZhOjM2NSkNCglhdCBvcmcuZWNsaXBzZS5qZmFjZS51dGlsLkRlbGVn YXRpbmdEcm9w
QWRhcHRlci5kcmFnT3ZlcihEZWxlZ2F0aW5nRHJvcEFkYXB0ZXIuamF2YTox ODIpDQoJYXQg
b3JnLmVjbGlwc2Uuc3d0LmRuZC5ETkRMaXN0ZW5lci5oYW5kbGVFdmVudChE TkRMaXN0ZW5l
ci5qYXZhOjgwKQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLkV2ZW50 VGFibGUuc2Vu
ZEV2ZW50KEV2ZW50VGFibGUuamF2YTo4NCkNCglhdCBvcmcuZWNsaXBzZS5z d3Qud2lkZ2V0
cy5XaWRnZXQuc2VuZEV2ZW50KFdpZGdldC5qYXZhOjEwMDMpDQoJYXQgb3Jn LmVjbGlwc2Uu
c3d0LndpZGdldHMuV2lkZ2V0LnNlbmRFdmVudChXaWRnZXQuamF2YToxMDI3 KQ0KCWF0IG9y
Zy5lY2xpcHNlLnN3dC53aWRnZXRzLldpZGdldC5zZW5kRXZlbnQoV2lkZ2V0 LmphdmE6MTAx
MikNCglhdCBvcmcuZWNsaXBzZS5zd3Qud2lkZ2V0cy5XaWRnZXQubm90aWZ5 TGlzdGVuZXJz
KFdpZGdldC5qYXZhOjc3MCkNCglhdCBvcmcuZWNsaXBzZS5zd3QuZG5kLkRy b3BUYXJnZXQu
RHJhZ092ZXIoRHJvcFRhcmdldC5qYXZhOjM2NSkNCglhdCBvcmcuZWNsaXBz ZS5zd3QuZG5k
LkRyb3BUYXJnZXQkMy5tZXRob2Q0KERyb3BUYXJnZXQuamF2YToyNDkpDQoJ YXQgb3JnLmVj
bGlwc2Uuc3d0LmludGVybmFsLm9sZS53aW4zMi5DT01PYmplY3QuY2FsbGJh Y2s0KENPTU9i
amVjdC5qYXZhOjEwMSkNCglhdCBvcmcuZWNsaXBzZS5zd3QuaW50ZXJuYWwu b2xlLndpbjMy
LkNPTS5Eb0RyYWdEcm9wKE5hdGl2ZSBNZXRob2QpDQoJYXQgb3JnLmVjbGlw c2Uuc3d0LmRu
ZC5EcmFnU291cmNlLmRyYWcoRHJhZ1NvdXJjZS5qYXZhOjM2MikNCglhdCBv cmcuZWNsaXBz
ZS5zd3QuZG5kLkRyYWdTb3VyY2UuYWNjZXNzJDAoRHJhZ1NvdXJjZS5qYXZh OjI4OCkNCglh
dCBvcmcuZWNsaXBzZS5zd3QuZG5kLkRyYWdTb3VyY2UkMS5oYW5kbGVFdmVu dChEcmFnU291
cmNlLmphdmE6MTcxKQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLkV2 ZW50VGFibGUu
c2VuZEV2ZW50KEV2ZW50VGFibGUuamF2YTo4NCkNCglhdCBvcmcuZWNsaXBz ZS5zd3Qud2lk
Z2V0cy5XaWRnZXQuc2VuZEV2ZW50KFdpZGdldC5qYXZhOjEwMDMpDQoJYXQg b3JnLmVjbGlw
c2Uuc3d0LndpZGdldHMuRGlzcGxheS5ydW5EZWZlcnJlZEV2ZW50cyhEaXNw bGF5LmphdmE6
MzgyMykNCglhdCBvcmcuZWNsaXBzZS5zd3Qud2lkZ2V0cy5EaXNwbGF5LnJl YWRBbmREaXNw
YXRjaChEaXNwbGF5LmphdmE6MzQyMikNCglhdCBvcmcuZWNsaXBzZS51aS5p bnRlcm5hbC5X
b3JrYmVuY2gucnVuRXZlbnRMb29wKFdvcmtiZW5jaC5qYXZhOjIzODQpDQoJ YXQgb3JnLmVj
bGlwc2UudWkuaW50ZXJuYWwuV29ya2JlbmNoLnJ1blVJKFdvcmtiZW5jaC5q YXZhOjIzNDgp
DQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuV29ya2JlbmNoLmFjY2Vz cyQ0KFdvcmti
ZW5jaC5qYXZhOjIyMDApDQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwu V29ya2JlbmNo
JDUucnVuKFdvcmtiZW5jaC5qYXZhOjQ5NSkNCglhdCBvcmcuZWNsaXBzZS5j b3JlLmRhdGFi
aW5kaW5nLm9ic2VydmFibGUuUmVhbG0ucnVuV2l0aERlZmF1bHQoUmVhbG0u amF2YToyODgp
DQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuV29ya2JlbmNoLmNyZWF0 ZUFuZFJ1bldv
cmtiZW5jaChXb3JrYmVuY2guamF2YTo0OTApDQoJYXQgb3JnLmVjbGlwc2Uu dWkuUGxhdGZv
cm1VSS5jcmVhdGVBbmRSdW5Xb3JrYmVuY2goUGxhdGZvcm1VSS5qYXZhOjE0 OSkNCglhdCBv
cmcuZWNsaXBzZS51aS5pbnRlcm5hbC5pZGUuYXBwbGljYXRpb24uSURFQXBw bGljYXRpb24u
c3RhcnQoSURFQXBwbGljYXRpb24uamF2YToxMTMpDQoJYXQgb3JnLmVjbGlw c2UuZXF1aW5v
eC5pbnRlcm5hbC5hcHAuRWNsaXBzZUFwcEhhbmRsZS5ydW4oRWNsaXBzZUFw cEhhbmRsZS5q
YXZhOjE5MykNCglhdCBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRpbWUuaW50ZXJu YWwuYWRhcHRv
ci5FY2xpcHNlQXBwTGF1bmNoZXIucnVuQXBwbGljYXRpb24oRWNsaXBzZUFw cExhdW5jaGVy
LmphdmE6MTEwKQ0KCWF0IG9yZy5lY2xpcHNlLmNvcmUucnVudGltZS5pbnRl cm5hbC5hZGFw
dG9yLkVjbGlwc2VBcHBMYXVuY2hlci5zdGFydChFY2xpcHNlQXBwTGF1bmNo ZXIuamF2YTo3
OSkNCglhdCBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRpbWUuYWRhcHRvci5FY2xp cHNlU3RhcnRl
ci5ydW4oRWNsaXBzZVN0YXJ0ZXIuamF2YTozODYpDQoJYXQgb3JnLmVjbGlw c2UuY29yZS5y
dW50aW1lLmFkYXB0b3IuRWNsaXBzZVN0YXJ0ZXIucnVuKEVjbGlwc2VTdGFy dGVyLmphdmE6
MTc5KQ0KCWF0IHN1bi5yZWZsZWN0Lk5hdGl2ZU1ldGhvZEFjY2Vzc29ySW1w bC5pbnZva2Uw
KE5hdGl2ZSBNZXRob2QpDQoJYXQgc3VuLnJlZmxlY3QuTmF0aXZlTWV0aG9k QWNjZXNzb3JJ
bXBsLmludm9rZShOYXRpdmVNZXRob2RBY2Nlc3NvckltcGwuamF2YTozOSkN CglhdCBzdW4u
cmVmbGVjdC5EZWxlZ2F0aW5nTWV0aG9kQWNjZXNzb3JJbXBsLmludm9rZShE ZWxlZ2F0aW5n
TWV0aG9kQWNjZXNzb3JJbXBsLmphdmE6MjUpDQoJYXQgamF2YS5sYW5nLnJl ZmxlY3QuTWV0
aG9kLmludm9rZShNZXRob2QuamF2YTo1ODUpDQoJYXQgb3JnLmVjbGlwc2Uu ZXF1aW5veC5s
YXVuY2hlci5NYWluLmludm9rZUZyYW1ld29yayhNYWluLmphdmE6NTQ5KQ0K CWF0IG9yZy5l
Y2xpcHNlLmVxdWlub3gubGF1bmNoZXIuTWFpbi5iYXNpY1J1bihNYWluLmph dmE6NTA0KQ0K
CWF0IG9yZy5lY2xpcHNlLmVxdWlub3gubGF1bmNoZXIuTWFpbi5ydW4oTWFp bi5qYXZhOjEy
MzYpDQoJYXQgb3JnLmVjbGlwc2UuZXF1aW5veC5sYXVuY2hlci5NYWluLm1h aW4oTWFpbi5q
YXZhOjEyMTIpDQpDYXVzZWQgYnk6IGphdmEubGFuZy5JbGxlZ2FsU3RhdGVF eGNlcHRpb246
IENhbm5vdCBhY3RpdmF0ZSByZWFkL3dyaXRlIHRyYW5zYWN0aW9uIGluIHJl YWQtb25seSB0
cmFuc2FjdGlvbiBjb250ZXh0DQoJYXQgb3JnLmVjbGlwc2UuZW1mLnRyYW5z YWN0aW9uLmlt
cGwuVHJhbnNhY3Rpb25hbEVkaXRpbmdEb21haW5JbXBsLmFjcXVpcmUoVHJh bnNhY3Rpb25h
bEVkaXRpbmdEb21haW5JbXBsLmphdmE6NTM3KQ0KCWF0IG9yZy5lY2xpcHNl LmVtZi50cmFu
c2FjdGlvbi5pbXBsLlRyYW5zYWN0aW9uYWxFZGl0aW5nRG9tYWluSW1wbC5h Y3RpdmF0ZShU
cmFuc2FjdGlvbmFsRWRpdGluZ0RvbWFpbkltcGwuamF2YTo0NjkpDQoJYXQg b3JnLmVjbGlw
c2UuZW1mLnRyYW5zYWN0aW9uLmltcGwuVHJhbnNhY3Rpb25JbXBsLnN0YXJ0 KFRyYW5zYWN0
aW9uSW1wbC5qYXZhOjE4NCkNCglhdCBvcmcuZWNsaXBzZS5lbWYudHJhbnNh Y3Rpb24uaW1w
bC5UcmFuc2FjdGlvbmFsRWRpdGluZ0RvbWFpbkltcGwuc3RhcnRUcmFuc2Fj dGlvbihUcmFu
c2FjdGlvbmFsRWRpdGluZ0RvbWFpbkltcGwuamF2YTozODUpDQoJYXQgb3Jn LmVjbGlwc2Uu
ZW1mLndvcmtzcGFjZS5BYnN0cmFjdEVNRk9wZXJhdGlvbi5jcmVhdGVUcmFu c2FjdGlvbihB
YnN0cmFjdEVNRk9wZXJhdGlvbi5qYXZhOjU0MykNCglhdCBvcmcuZWNsaXBz ZS5lbWYud29y
a3NwYWNlLkFic3RyYWN0RU1GT3BlcmF0aW9uLmV4ZWN1dGUoQWJzdHJhY3RF TUZPcGVyYXRp
b24uamF2YToxNjYpDQoJYXQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuZGlh Z3JhbS51aS5j
b21tYW5kcy5TZW1hbnRpY0NyZWF0ZUNvbW1hbmQuZG9FeGVjdXRlV2l0aFJl c3VsdChTZW1h
bnRpY0NyZWF0ZUNvbW1hbmQuamF2YTo3MSkNCglhdCBvcmcuZWNsaXBzZS5n bWYucnVudGlt
ZS5jb21tb24uY29yZS5jb21tYW5kLkFic3RyYWN0Q29tbWFuZC5leGVjdXRl KEFic3RyYWN0
Q29tbWFuZC5qYXZhOjEzNSkNCglhdCBvcmcuZWNsaXBzZS5nbWYucnVudGlt ZS5jb21tb24u
Y29yZS5jb21tYW5kLkNvbXBvc2l0ZUNvbW1hbmQuZG9FeGVjdXRlV2l0aFJl c3VsdChDb21w
b3NpdGVDb21tYW5kLmphdmE6NDAzKQ0KCWF0IG9yZy5lY2xpcHNlLmdtZi5y dW50aW1lLmNv
bW1vbi5jb3JlLmNvbW1hbmQuQWJzdHJhY3RDb21tYW5kLmV4ZWN1dGUoQWJz dHJhY3RDb21t
YW5kLmphdmE6MTM1KQ0KCWF0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLmNv bW1vbi5jb3Jl
LmNvbW1hbmQuQ29tcG9zaXRlQ29tbWFuZC5kb0V4ZWN1dGVXaXRoUmVzdWx0 KENvbXBvc2l0
ZUNvbW1hbmQuamF2YTo0MDMpDQoJYXQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRp bWUuY29tbW9u
LmNvcmUuY29tbWFuZC5BYnN0cmFjdENvbW1hbmQuZXhlY3V0ZShBYnN0cmFj dENvbW1hbmQu
amF2YToxMzUpDQoJYXQgb3JnLmVjbGlwc2UuY29yZS5jb21tYW5kcy5vcGVy YXRpb25zLkRl
ZmF1bHRPcGVyYXRpb25IaXN0b3J5LmV4ZWN1dGUoRGVmYXVsdE9wZXJhdGlv bkhpc3Rvcnku
amF2YTo1MTEpDQoJLi4uIDUzIG1vcmUNCg0KIUVOVFJZIG9yZy5lY2xpcHNl LmdtZi5ydW50
aW1lLmRpYWdyYW0udWkgNCA0IDIwMDktMDQtMjcgMTg6MTc6MzguMDc3DQoh TUVTU0FHRSBl
eGVjdXRlDQohU1RBQ0sgMA0Kb3JnLmVjbGlwc2UuY29yZS5jb21tYW5kcy5F eGVjdXRpb25F
eGNlcHRpb246IFdoaWxlIGV4ZWN1dGluZyB0aGUgb3BlcmF0aW9uLCBhbiBl eGNlcHRpb24g
b2NjdXJyZWQNCglhdCBvcmcuZWNsaXBzZS5jb3JlLmNvbW1hbmRzLm9wZXJh dGlvbnMuRGVm
YXVsdE9wZXJhdGlvbkhpc3RvcnkuZXhlY3V0ZShEZWZhdWx0T3BlcmF0aW9u SGlzdG9yeS5q
YXZhOjUxOSkNCglhdCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5kaWFncmFt LnVpLnBhcnRz
LkRpYWdyYW1Db21tYW5kU3RhY2suZXhlY3V0ZShEaWFncmFtQ29tbWFuZFN0 YWNrLmphdmE6
MjA1KQ0KCWF0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLmRpYWdyYW0udWku cGFydHMuRGlh
Z3JhbUNvbW1hbmRTdGFjay5leGVjdXRlKERpYWdyYW1Db21tYW5kU3RhY2su amF2YToxNjgp
DQoJYXQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51aS5wYXJ0 cy5EaWFncmFt
Q29tbWFuZFN0YWNrLmV4ZWN1dGUoRGlhZ3JhbUNvbW1hbmRTdGFjay5qYXZh OjE1NSkNCglh
dCBtZGEuY3VzdG9tLmVkaXRwb2xpY2llcy5UcmFuc2ZvUHJvamVjdERpYWdy YW1EcmFnRHJv
cEVkaXRQb2xpY3kuZ2V0RHJvcE9iamVjdHNDb21tYW5kKFRyYW5zZm9Qcm9q ZWN0RGlhZ3Jh
bURyYWdEcm9wRWRpdFBvbGljeS5qYXZhOjEwOSkNCglhdCBvcmcuZWNsaXBz ZS5nbWYucnVu
dGltZS5kaWFncmFtLnVpLmVkaXRwb2xpY2llcy5EcmFnRHJvcEVkaXRQb2xp Y3kuZ2V0Q29t
bWFuZChEcmFnRHJvcEVkaXRQb2xpY3kuamF2YTo4MCkNCglhdCBvcmcuZWNs aXBzZS5nZWYu
ZWRpdHBhcnRzLkFic3RyYWN0RWRpdFBhcnQuZ2V0Q29tbWFuZChBYnN0cmFj dEVkaXRQYXJ0
LmphdmE6NDczKQ0KCWF0IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLmRpYWdy YW0udWkuZWRp
dHBhcnRzLkdyYXBoaWNhbEVkaXRQYXJ0LmFjY2VzcyQxKEdyYXBoaWNhbEVk aXRQYXJ0Lmph
dmE6MSkNCglhdCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5kaWFncmFtLnVp LmVkaXRwYXJ0
cy5HcmFwaGljYWxFZGl0UGFydCQxLnJ1bihHcmFwaGljYWxFZGl0UGFydC5q YXZhOjQ2NikN
CglhdCBvcmcuZWNsaXBzZS5lbWYudHJhbnNhY3Rpb24uaW1wbC5UcmFuc2Fj dGlvbmFsRWRp
dGluZ0RvbWFpbkltcGwucnVuRXhjbHVzaXZlKFRyYW5zYWN0aW9uYWxFZGl0 aW5nRG9tYWlu
SW1wbC5qYXZhOjI4OSkNCglhdCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5k aWFncmFtLnVp
LmVkaXRwYXJ0cy5HcmFwaGljYWxFZGl0UGFydC5nZXRDb21tYW5kKEdyYXBo aWNhbEVkaXRQ
YXJ0LmphdmE6NDYxKQ0KCWF0IG9yZy5lY2xpcHNlLmdlZi5kbmQuQWJzdHJh Y3RUcmFuc2Zl
ckRyb3BUYXJnZXRMaXN0ZW5lci5nZXRDb21tYW5kKEFic3RyYWN0VHJhbnNm ZXJEcm9wVGFy
Z2V0TGlzdGVuZXIuamF2YToyMDEpDQoJYXQgb3JnLmVjbGlwc2UuZ21mLnJ1 bnRpbWUuZGlh
Z3JhbS51aS5wYXJ0cy5EaWFncmFtRHJvcFRhcmdldExpc3RlbmVyLmlzRW5h YmxlZChEaWFn
cmFtRHJvcFRhcmdldExpc3RlbmVyLmphdmE6MjIzKQ0KCWF0IG9yZy5lY2xp cHNlLmdtZi5y
dW50aW1lLmRpYWdyYW0udWkuaW50ZXJuYWwucGFydHMuSW1hZ2VGaWxlRHJv cFRhcmdldExp
c3RlbmVyLmlzRW5hYmxlZChJbWFnZUZpbGVEcm9wVGFyZ2V0TGlzdGVuZXIu amF2YToxMDEp
DQoJYXQgb3JnLmVjbGlwc2UuamZhY2UudXRpbC5EZWxlZ2F0aW5nRHJvcEFk YXB0ZXIudXBk
YXRlQ3VycmVudExpc3RlbmVyKERlbGVnYXRpbmdEcm9wQWRhcHRlci5qYXZh OjM2NSkNCglh
dCBvcmcuZWNsaXBzZS5qZmFjZS51dGlsLkRlbGVnYXRpbmdEcm9wQWRhcHRl ci5kcm9wKERl
bGVnYXRpbmdEcm9wQWRhcHRlci5qYXZhOjIwNykNCglhdCBvcmcuZWNsaXBz ZS5zd3QuZG5k
LkRORExpc3RlbmVyLmhhbmRsZUV2ZW50KERORExpc3RlbmVyLmphdmE6OTAp DQoJYXQgb3Jn
LmVjbGlwc2Uuc3d0LndpZGdldHMuRXZlbnRUYWJsZS5zZW5kRXZlbnQoRXZl bnRUYWJsZS5q
YXZhOjg0KQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLldpZGdldC5z ZW5kRXZlbnQo
V2lkZ2V0LmphdmE6MTAwMykNCglhdCBvcmcuZWNsaXBzZS5zd3Qud2lkZ2V0 cy5XaWRnZXQu
c2VuZEV2ZW50KFdpZGdldC5qYXZhOjEwMjcpDQoJYXQgb3JnLmVjbGlwc2Uu c3d0LndpZGdl
dHMuV2lkZ2V0LnNlbmRFdmVudChXaWRnZXQuamF2YToxMDEyKQ0KCWF0IG9y Zy5lY2xpcHNl
LnN3dC53aWRnZXRzLldpZGdldC5ub3RpZnlMaXN0ZW5lcnMoV2lkZ2V0Lmph dmE6NzcwKQ0K
CWF0IG9yZy5lY2xpcHNlLnN3dC5kbmQuRHJvcFRhcmdldC5Ecm9wKERyb3BU YXJnZXQuamF2
YTo0NTUpDQoJYXQgb3JnLmVjbGlwc2Uuc3d0LmRuZC5Ecm9wVGFyZ2V0JDMu bWV0aG9kNihE
cm9wVGFyZ2V0LmphdmE6MjU3KQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC5pbnRl cm5hbC5vbGUu
d2luMzIuQ09NT2JqZWN0LmNhbGxiYWNrNihDT01PYmplY3QuamF2YToxMTkp DQoJYXQgb3Jn
LmVjbGlwc2Uuc3d0LmludGVybmFsLm9sZS53aW4zMi5DT00uRG9EcmFnRHJv cChOYXRpdmUg
TWV0aG9kKQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC5kbmQuRHJhZ1NvdXJjZS5k cmFnKERyYWdT
b3VyY2UuamF2YTozNjIpDQoJYXQgb3JnLmVjbGlwc2Uuc3d0LmRuZC5EcmFn U291cmNlLmFj
Y2VzcyQwKERyYWdTb3VyY2UuamF2YToyODgpDQoJYXQgb3JnLmVjbGlwc2Uu c3d0LmRuZC5E
cmFnU291cmNlJDEuaGFuZGxlRXZlbnQoRHJhZ1NvdXJjZS5qYXZhOjE3MSkN CglhdCBvcmcu
ZWNsaXBzZS5zd3Qud2lkZ2V0cy5FdmVudFRhYmxlLnNlbmRFdmVudChFdmVu dFRhYmxlLmph
dmE6ODQpDQoJYXQgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuV2lkZ2V0LnNl bmRFdmVudChX
aWRnZXQuamF2YToxMDAzKQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRz LkRpc3BsYXku
cnVuRGVmZXJyZWRFdmVudHMoRGlzcGxheS5qYXZhOjM4MjMpDQoJYXQgb3Jn LmVjbGlwc2Uu
c3d0LndpZGdldHMuRGlzcGxheS5yZWFkQW5kRGlzcGF0Y2goRGlzcGxheS5q YXZhOjM0MjIp
DQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuV29ya2JlbmNoLnJ1bkV2 ZW50TG9vcChX
b3JrYmVuY2guamF2YToyMzg0KQ0KCWF0IG9yZy5lY2xpcHNlLnVpLmludGVy bmFsLldvcmti
ZW5jaC5ydW5VSShXb3JrYmVuY2guamF2YToyMzQ4KQ0KCWF0IG9yZy5lY2xp cHNlLnVpLmlu
dGVybmFsLldvcmtiZW5jaC5hY2Nlc3MkNChXb3JrYmVuY2guamF2YToyMjAw KQ0KCWF0IG9y
Zy5lY2xpcHNlLnVpLmludGVybmFsLldvcmtiZW5jaCQ1LnJ1bihXb3JrYmVu Y2guamF2YTo0
OTUpDQoJYXQgb3JnLmVjbGlwc2UuY29yZS5kYXRhYmluZGluZy5vYnNlcnZh YmxlLlJlYWxt
LnJ1bldpdGhEZWZhdWx0KFJlYWxtLmphdmE6Mjg4KQ0KCWF0IG9yZy5lY2xp cHNlLnVpLmlu
dGVybmFsLldvcmtiZW5jaC5jcmVhdGVBbmRSdW5Xb3JrYmVuY2goV29ya2Jl bmNoLmphdmE6
NDkwKQ0KCWF0IG9yZy5lY2xpcHNlLnVpLlBsYXRmb3JtVUkuY3JlYXRlQW5k UnVuV29ya2Jl
bmNoKFBsYXRmb3JtVUkuamF2YToxNDkpDQoJYXQgb3JnLmVjbGlwc2UudWku aW50ZXJuYWwu
aWRlLmFwcGxpY2F0aW9uLklERUFwcGxpY2F0aW9uLnN0YXJ0KElERUFwcGxp Y2F0aW9uLmph
dmE6MTEzKQ0KCWF0IG9yZy5lY2xpcHNlLmVxdWlub3guaW50ZXJuYWwuYXBw LkVjbGlwc2VB
cHBIYW5kbGUucnVuKEVjbGlwc2VBcHBIYW5kbGUuamF2YToxOTMpDQoJYXQg b3JnLmVjbGlw
c2UuY29yZS5ydW50aW1lLmludGVybmFsLmFkYXB0b3IuRWNsaXBzZUFwcExh dW5jaGVyLnJ1
bkFwcGxpY2F0aW9uKEVjbGlwc2VBcHBMYXVuY2hlci5qYXZhOjExMCkNCglh dCBvcmcuZWNs
aXBzZS5jb3JlLnJ1bnRpbWUuaW50ZXJuYWwuYWRhcHRvci5FY2xpcHNlQXBw TGF1bmNoZXIu
c3RhcnQoRWNsaXBzZUFwcExhdW5jaGVyLmphdmE6NzkpDQoJYXQgb3JnLmVj bGlwc2UuY29y
ZS5ydW50aW1lLmFkYXB0b3IuRWNsaXBzZVN0YXJ0ZXIucnVuKEVjbGlwc2VT dGFydGVyLmph
dmE6Mzg2KQ0KCWF0IG9yZy5lY2xpcHNlLmNvcmUucnVudGltZS5hZGFwdG9y LkVjbGlwc2VT
dGFydGVyLnJ1bihFY2xpcHNlU3RhcnRlci5qYXZhOjE3OSkNCglhdCBzdW4u cmVmbGVjdC5O
YXRpdmVNZXRob2RBY2Nlc3NvckltcGwuaW52b2tlMChOYXRpdmUgTWV0aG9k KQ0KCWF0IHN1
bi5yZWZsZWN0Lk5hdGl2ZU1ldGhvZEFjY2Vzc29ySW1wbC5pbnZva2UoTmF0 aXZlTWV0aG9k
QWNjZXNzb3JJbXBsLmphdmE6MzkpDQoJYXQgc3VuLnJlZmxlY3QuRGVsZWdh dGluZ01ldGhv
ZEFjY2Vzc29ySW1wbC5pbnZva2UoRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29y SW1wbC5qYXZh
OjI1KQ0KCWF0IGphdmEubGFuZy5yZWZsZWN0Lk1ldGhvZC5pbnZva2UoTWV0 aG9kLmphdmE6
NTg1KQ0KCWF0IG9yZy5lY2xpcHNlLmVxdWlub3gubGF1bmNoZXIuTWFpbi5p bnZva2VGcmFt
ZXdvcmsoTWFpbi5qYXZhOjU0OSkNCglhdCBvcmcuZWNsaXBzZS5lcXVpbm94 LmxhdW5jaGVy
Lk1haW4uYmFzaWNSdW4oTWFpbi5qYXZhOjUwNCkNCglhdCBvcmcuZWNsaXBz ZS5lcXVpbm94
LmxhdW5jaGVyLk1haW4ucnVuKE1haW4uamF2YToxMjM2KQ0KCWF0IG9yZy5l Y2xpcHNlLmVx
dWlub3gubGF1bmNoZXIuTWFpbi5tYWluKE1haW4uamF2YToxMjEyKQ0KQ2F1 c2VkIGJ5OiBq
YXZhLmxhbmcuSWxsZWdhbFN0YXRlRXhjZXB0aW9uOiBDYW5ub3QgYWN0aXZh dGUgcmVhZC93
cml0ZSB0cmFuc2FjdGlvbiBpbiByZWFkLW9ubHkgdHJhbnNhY3Rpb24gY29u dGV4dA0KCWF0
IG9yZy5lY2xpcHNlLmVtZi50cmFuc2FjdGlvbi5pbXBsLlRyYW5zYWN0aW9u YWxFZGl0aW5n
RG9tYWluSW1wbC5hY3F1aXJlKFRyYW5zYWN0aW9uYWxFZGl0aW5nRG9tYWlu SW1wbC5qYXZh
OjUzNykNCglhdCBvcmcuZWNsaXBzZS5lbWYudHJhbnNhY3Rpb24uaW1wbC5U cmFuc2FjdGlv
bmFsRWRpdGluZ0RvbWFpbkltcGwuYWN0aXZhdGUoVHJhbnNhY3Rpb25hbEVk aXRpbmdEb21h
aW5JbXBsLmphdmE6NDY5KQ0KCWF0IG9yZy5lY2xpcHNlLmVtZi50cmFuc2Fj dGlvbi5pbXBs
LlRyYW5zYWN0aW9uSW1wbC5zdGFydChUcmFuc2FjdGlvbkltcGwuamF2YTox ODQpDQoJYXQg
b3JnLmVjbGlwc2UuZW1mLnRyYW5zYWN0aW9uLmltcGwuVHJhbnNhY3Rpb25h bEVkaXRpbmdE
b21haW5JbXBsLnN0YXJ0VHJhbnNhY3Rpb24oVHJhbnNhY3Rpb25hbEVkaXRp bmdEb21haW5J
bXBsLmphdmE6Mzg1KQ0KCWF0IG9yZy5lY2xpcHNlLmVtZi53b3Jrc3BhY2Uu QWJzdHJhY3RF
TUZPcGVyYXRpb24uY3JlYXRlVHJhbnNhY3Rpb24oQWJzdHJhY3RFTUZPcGVy YXRpb24uamF2
YTo1NDMpDQoJYXQgb3JnLmVjbGlwc2UuZW1mLndvcmtzcGFjZS5BYnN0cmFj dEVNRk9wZXJh
dGlvbi5leGVjdXRlKEFic3RyYWN0RU1GT3BlcmF0aW9uLmphdmE6MTY2KQ0K CWF0IG9yZy5l
Y2xpcHNlLmdtZi5ydW50aW1lLmRpYWdyYW0udWkuY29tbWFuZHMuU2VtYW50 aWNDcmVhdGVD
b21tYW5kLmRvRXhlY3V0ZVdpdGhSZXN1bHQoU2VtYW50aWNDcmVhdGVDb21t YW5kLmphdmE6
NzEpDQoJYXQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuY29tbW9uLmNvcmUu Y29tbWFuZC5B
YnN0cmFjdENvbW1hbmQuZXhlY3V0ZShBYnN0cmFjdENvbW1hbmQuamF2YTox MzUpDQoJYXQg
b3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuY29tbW9uLmNvcmUuY29tbWFuZC5D b21wb3NpdGVD
b21tYW5kLmRvRXhlY3V0ZVdpdGhSZXN1bHQoQ29tcG9zaXRlQ29tbWFuZC5q YXZhOjQwMykN
CglhdCBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5jb21tb24uY29yZS5jb21t YW5kLkFic3Ry
YWN0Q29tbWFuZC5leGVjdXRlKEFic3RyYWN0Q29tbWFuZC5qYXZhOjEzNSkN CglhdCBvcmcu
ZWNsaXBzZS5nbWYucnVudGltZS5jb21tb24uY29yZS5jb21tYW5kLkNvbXBv c2l0ZUNvbW1h
bmQuZG9FeGVjdXRlV2l0aFJlc3VsdChDb21wb3NpdGVDb21tYW5kLmphdmE6 NDAzKQ0KCWF0
IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLmNvbW1vbi5jb3JlLmNvbW1hbmQu QWJzdHJhY3RD
b21tYW5kLmV4ZWN1dGUoQWJzdHJhY3RDb21tYW5kLmphdmE6MTM1KQ0KCWF0 IG9yZy5lY2xp
cHNlLmNvcmUuY29tbWFuZHMub3BlcmF0aW9ucy5EZWZhdWx0T3BlcmF0aW9u SGlzdG9yeS5l
eGVjdXRlKERlZmF1bHRPcGVyYXRpb25IaXN0b3J5LmphdmE6NTExKQ0KCS4u LiA1MyBtb3Jl
DQoNCiFFTlRSWSBvcmcuZWNsaXBzZS5nbWYucnVudGltZS5kaWFncmFtLnVp IDQgNCAyMDA5
LTA0LTI3IDE4OjE3OjM4LjA5Mw0KIU1FU1NBR0UgZXhlY3V0ZQ0KIVNUQUNL IDANCm9yZy5l
Y2xpcHNlLmNvcmUuY29tbWFuZHMuRXhlY3V0aW9uRXhjZXB0aW9uOiBXaGls ZSBleGVjdXRp
bmcgdGhlIG9wZXJhdGlvbiwgYW4gZXhjZXB0aW9uIG9jY3VycmVkDQoJYXQg b3JnLmVjbGlw
c2UuY29yZS5jb21tYW5kcy5vcGVyYXRpb25zLkRlZmF1bHRPcGVyYXRpb25I aXN0b3J5LmV4
ZWN1dGUoRGVmYXVsdE9wZXJhdGlvbkhpc3RvcnkuamF2YTo1MTkpDQoJYXQg b3JnLmVjbGlw
c2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51aS5wYXJ0cy5EaWFncmFtQ29tbWFu ZFN0YWNrLmV4
ZWN1dGUoRGlhZ3JhbUNvbW1hbmRTdGFjay5qYXZhOjIwNSkNCglhdCBvcmcu ZWNsaXBzZS5n
bWYucnVudGltZS5kaWFncmFtLnVpLnBhcnRzLkRpYWdyYW1Db21tYW5kU3Rh Y2suZXhlY3V0
ZShEaWFncmFtQ29tbWFuZFN0YWNrLmphdmE6MTY4KQ0KCWF0IG9yZy5lY2xp cHNlLmdtZi5y
dW50aW1lLmRpYWdyYW0udWkucGFydHMuRGlhZ3JhbUNvbW1hbmRTdGFjay5l eGVjdXRlKERp
YWdyYW1Db21tYW5kU3RhY2suamF2YToxNTUpDQoJYXQgbWRhLmN1c3RvbS5l ZGl0cG9saWNp
ZXMuVHJhbnNmb1Byb2plY3REaWFncmFtRHJhZ0Ryb3BFZGl0UG9saWN5Lmdl dERyb3BPYmpl
Y3RzQ29tbWFuZChUcmFuc2ZvUHJvamVjdERpYWdyYW1EcmFnRHJvcEVkaXRQ b2xpY3kuamF2
YToxMDkpDQoJYXQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51 aS5lZGl0cG9s
aWNpZXMuRHJhZ0Ryb3BFZGl0UG9saWN5LmdldENvbW1hbmQoRHJhZ0Ryb3BF ZGl0UG9saWN5
LmphdmE6ODApDQoJYXQgb3JnLmVjbGlwc2UuZ2VmLmVkaXRwYXJ0cy5BYnN0 cmFjdEVkaXRQ
YXJ0LmdldENvbW1hbmQoQWJzdHJhY3RFZGl0UGFydC5qYXZhOjQ3MykNCglh dCBvcmcuZWNs
aXBzZS5nbWYucnVudGltZS5kaWFncmFtLnVpLmVkaXRwYXJ0cy5HcmFwaGlj YWxFZGl0UGFy
dC5hY2Nlc3MkMShHcmFwaGljYWxFZGl0UGFydC5qYXZhOjEpDQoJYXQgb3Jn LmVjbGlwc2Uu
Z21mLnJ1bnRpbWUuZGlhZ3JhbS51aS5lZGl0cGFydHMuR3JhcGhpY2FsRWRp dFBhcnQkMS5y
dW4oR3JhcGhpY2FsRWRpdFBhcnQuamF2YTo0NjYpDQoJYXQgb3JnLmVjbGlw c2UuZW1mLnRy
YW5zYWN0aW9uLmltcGwuVHJhbnNhY3Rpb25hbEVkaXRpbmdEb21haW5JbXBs LnJ1bkV4Y2x1
c2l2ZShUcmFuc2FjdGlvbmFsRWRpdGluZ0RvbWFpbkltcGwuamF2YToyODkp DQoJYXQgb3Jn
LmVjbGlwc2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51aS5lZGl0cGFydHMuR3Jh cGhpY2FsRWRp
dFBhcnQuZ2V0Q29tbWFuZChHcmFwaGljYWxFZGl0UGFydC5qYXZhOjQ2MSkN CglhdCBvcmcu
ZWNsaXBzZS5nZWYuZG5kLkFic3RyYWN0VHJhbnNmZXJEcm9wVGFyZ2V0TGlz dGVuZXIuZ2V0
Q29tbWFuZChBYnN0cmFjdFRyYW5zZmVyRHJvcFRhcmdldExpc3RlbmVyLmph dmE6MjAxKQ0K
CWF0IG9yZy5lY2xpcHNlLmdlZi5kbmQuQWJzdHJhY3RUcmFuc2ZlckRyb3BU YXJnZXRMaXN0
ZW5lci5oYW5kbGVEcm9wKEFic3RyYWN0VHJhbnNmZXJEcm9wVGFyZ2V0TGlz dGVuZXIuamF2
YTozMTIpDQoJYXQgb3JnLmVjbGlwc2UuZ21mLnJ1bnRpbWUuZGlhZ3JhbS51 aS5wYXJ0cy5E
aWFncmFtRHJvcFRhcmdldExpc3RlbmVyLmhhbmRsZURyb3AoRGlhZ3JhbURy b3BUYXJnZXRM
aXN0ZW5lci5qYXZhOjE1MCkNCglhdCBvcmcuZWNsaXBzZS5nZWYuZG5kLkFi c3RyYWN0VHJh
bnNmZXJEcm9wVGFyZ2V0TGlzdGVuZXIuZHJvcChBYnN0cmFjdFRyYW5zZmVy RHJvcFRhcmdl
dExpc3RlbmVyLmphdmE6MTcxKQ0KCWF0IG9yZy5lY2xpcHNlLmpmYWNlLnV0 aWwuRGVsZWdh
dGluZ0Ryb3BBZGFwdGVyJDMucnVuKERlbGVnYXRpbmdEcm9wQWRhcHRlci5q YXZhOjIxMSkN
CglhdCBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRpbWUuU2FmZVJ1bm5lci5ydW4o U2FmZVJ1bm5l
ci5qYXZhOjM3KQ0KCWF0IG9yZy5lY2xpcHNlLmNvcmUucnVudGltZS5QbGF0 Zm9ybS5ydW4o
UGxhdGZvcm0uamF2YTo4ODApDQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJu YWwuSkZhY2VV
dGlsJDEucnVuKEpGYWNlVXRpbC5qYXZhOjQ4KQ0KCWF0IG9yZy5lY2xpcHNl LmpmYWNlLnV0
aWwuU2FmZVJ1bm5hYmxlLnJ1bihTYWZlUnVubmFibGUuamF2YToxNzUpDQoJ YXQgb3JnLmVj
bGlwc2UuamZhY2UudXRpbC5EZWxlZ2F0aW5nRHJvcEFkYXB0ZXIuZHJvcChE ZWxlZ2F0aW5n
RHJvcEFkYXB0ZXIuamF2YToyMDkpDQoJYXQgb3JnLmVjbGlwc2Uuc3d0LmRu ZC5ETkRMaXN0
ZW5lci5oYW5kbGVFdmVudChETkRMaXN0ZW5lci5qYXZhOjkwKQ0KCWF0IG9y Zy5lY2xpcHNl
LnN3dC53aWRnZXRzLkV2ZW50VGFibGUuc2VuZEV2ZW50KEV2ZW50VGFibGUu amF2YTo4NCkN
CglhdCBvcmcuZWNsaXBzZS5zd3Qud2lkZ2V0cy5XaWRnZXQuc2VuZEV2ZW50 KFdpZGdldC5q
YXZhOjEwMDMpDQoJYXQgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuV2lkZ2V0 LnNlbmRFdmVu
dChXaWRnZXQuamF2YToxMDI3KQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRn ZXRzLldpZGdl
dC5zZW5kRXZlbnQoV2lkZ2V0LmphdmE6MTAxMikNCglhdCBvcmcuZWNsaXBz ZS5zd3Qud2lk
Z2V0cy5XaWRnZXQubm90aWZ5TGlzdGVuZXJzKFdpZGdldC5qYXZhOjc3MCkN CglhdCBvcmcu
ZWNsaXBzZS5zd3QuZG5kLkRyb3BUYXJnZXQuRHJvcChEcm9wVGFyZ2V0Lmph dmE6NDU1KQ0K
CWF0IG9yZy5lY2xpcHNlLnN3dC5kbmQuRHJvcFRhcmdldCQzLm1ldGhvZDYo RHJvcFRhcmdl
dC5qYXZhOjI1NykNCglhdCBvcmcuZWNsaXBzZS5zd3QuaW50ZXJuYWwub2xl LndpbjMyLkNP
TU9iamVjdC5jYWxsYmFjazYoQ09NT2JqZWN0LmphdmE6MTE5KQ0KCWF0IG9y Zy5lY2xpcHNl
LnN3dC5pbnRlcm5hbC5vbGUud2luMzIuQ09NLkRvRHJhZ0Ryb3AoTmF0aXZl IE1ldGhvZCkN
CglhdCBvcmcuZWNsaXBzZS5zd3QuZG5kLkRyYWdTb3VyY2UuZHJhZyhEcmFn U291cmNlLmph
dmE6MzYyKQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC5kbmQuRHJhZ1NvdXJjZS5h Y2Nlc3MkMChE
cmFnU291cmNlLmphdmE6Mjg4KQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC5kbmQu RHJhZ1NvdXJj
ZSQxLmhhbmRsZUV2ZW50KERyYWdTb3VyY2UuamF2YToxNzEpDQoJYXQgb3Jn LmVjbGlwc2Uu
c3d0LndpZGdldHMuRXZlbnRUYWJsZS5zZW5kRXZlbnQoRXZlbnRUYWJsZS5q YXZhOjg0KQ0K
CWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLldpZGdldC5zZW5kRXZlbnQo V2lkZ2V0Lmph
dmE6MTAwMykNCglhdCBvcmcuZWNsaXBzZS5zd3Qud2lkZ2V0cy5EaXNwbGF5 LnJ1bkRlZmVy
cmVkRXZlbnRzKERpc3BsYXkuamF2YTozODIzKQ0KCWF0IG9yZy5lY2xpcHNl LnN3dC53aWRn
ZXRzLkRpc3BsYXkucmVhZEFuZERpc3BhdGNoKERpc3BsYXkuamF2YTozNDIy KQ0KCWF0IG9y
Zy5lY2xpcHNlLnVpLmludGVybmFsLldvcmtiZW5jaC5ydW5FdmVudExvb3Ao V29ya2JlbmNo
LmphdmE6MjM4NCkNCglhdCBvcmcuZWNsaXBzZS51aS5pbnRlcm5hbC5Xb3Jr YmVuY2gucnVu
VUkoV29ya2JlbmNoLmphdmE6MjM0OCkNCglhdCBvcmcuZWNsaXBzZS51aS5p bnRlcm5hbC5X
b3JrYmVuY2guYWNjZXNzJDQoV29ya2JlbmNoLmphdmE6MjIwMCkNCglhdCBv cmcuZWNsaXBz
ZS51aS5pbnRlcm5hbC5Xb3JrYmVuY2gkNS5ydW4oV29ya2JlbmNoLmphdmE6 NDk1KQ0KCWF0
IG9yZy5lY2xpcHNlLmNvcmUuZGF0YWJpbmRpbmcub2JzZXJ2YWJsZS5SZWFs bS5ydW5XaXRo
RGVmYXVsdChSZWFsbS5qYXZhOjI4OCkNCglhdCBvcmcuZWNsaXBzZS51aS5p bnRlcm5hbC5X
b3JrYmVuY2guY3JlYXRlQW5kUnVuV29ya2JlbmNoKFdvcmtiZW5jaC5qYXZh OjQ5MCkNCglh
dCBvcmcuZWNsaXBzZS51aS5QbGF0Zm9ybVVJLmNyZWF0ZUFuZFJ1bldvcmti ZW5jaChQbGF0
Zm9ybVVJLmphdmE6MTQ5KQ0KCWF0IG9yZy5lY2xpcHNlLnVpLmludGVybmFs LmlkZS5hcHBs
aWNhdGlvbi5JREVBcHBsaWNhdGlvbi5zdGFydChJREVBcHBsaWNhdGlvbi5q YXZhOjExMykN
CglhdCBvcmcuZWNsaXBzZS5lcXVpbm94LmludGVybmFsLmFwcC5FY2xpcHNl QXBwSGFuZGxl
LnJ1bihFY2xpcHNlQXBwSGFuZGxlLmphdmE6MTkzKQ0KCWF0IG9yZy5lY2xp cHNlLmNvcmUu
cnVudGltZS5pbnRlcm5hbC5hZGFwdG9yLkVjbGlwc2VBcHBMYXVuY2hlci5y dW5BcHBsaWNh
dGlvbihFY2xpcHNlQXBwTGF1bmNoZXIuamF2YToxMTApDQoJYXQgb3JnLmVj bGlwc2UuY29y
ZS5ydW50aW1lLmludGVybmFsLmFkYXB0b3IuRWNsaXBzZUFwcExhdW5jaGVy LnN0YXJ0KEVj
bGlwc2VBcHBMYXVuY2hlci5qYXZhOjc5KQ0KCWF0IG9yZy5lY2xpcHNlLmNv cmUucnVudGlt
ZS5hZGFwdG9yLkVjbGlwc2VTdGFydGVyLnJ1bihFY2xpcHNlU3RhcnRlci5q YXZhOjM4NikN
CglhdCBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRpbWUuYWRhcHRvci5FY2xpcHNl U3RhcnRlci5y
dW4oRWNsaXBzZVN0YXJ0ZXIuamF2YToxNzkpDQoJYXQgc3VuLnJlZmxlY3Qu TmF0aXZlTWV0
aG9kQWNjZXNzb3JJbXBsLmludm9rZTAoTmF0aXZlIE1ldGhvZCkNCglhdCBz dW4ucmVmbGVj
dC5OYXRpdmVNZXRob2RBY2Nlc3NvckltcGwuaW52b2tlKE5hdGl2ZU1ldGhv ZEFjY2Vzc29y
SW1wbC5qYXZhOjM5KQ0KCWF0IHN1bi5yZWZsZWN0LkRlbGVnYXRpbmdNZXRo b2RBY2Nlc3Nv
ckltcGwuaW52b2tlKERlbGVnYXRpbmdNZXRob2RBY2Nlc3NvckltcGwuamF2 YToyNSkNCglh
dCBqYXZhLmxhbmcucmVmbGVjdC5NZXRob2QuaW52b2tlKE1ldGhvZC5qYXZh OjU4NSkNCglh
dCBvcmcuZWNsaXBzZS5lcXVpbm94LmxhdW5jaGVyLk1haW4uaW52b2tlRnJh bWV3b3JrKE1h
aW4uamF2YTo1NDkpDQoJYXQgb3JnLmVjbGlwc2UuZXF1aW5veC5sYXVuY2hl ci5NYWluLmJh
c2ljUnVuKE1haW4uamF2YTo1MDQpDQoJYXQgb3JnLmVjbGlwc2UuZXF1aW5v eC5sYXVuY2hl
ci5NYWluLnJ1bihNYWluLmphdmE6MTIzNikNCglhdCBvcmcuZWNsaXBzZS5l cXVpbm94Lmxh
dW5jaGVyLk1haW4ubWFpbihNYWluLmphdmE6MTIxMikNCkNhdXNlZCBieTog amF2YS5sYW5n
LklsbGVnYWxTdGF0ZUV4Y2VwdGlvbjogQ2Fubm90IGFjdGl2YXRlIHJlYWQv d3JpdGUgdHJh
bnNhY3Rpb24gaW4gcmVhZC1vbmx5IHRyYW5zYWN0aW9uIGNvbnRleHQNCglh dCBvcmcuZWNs
aXBzZS5lbWYudHJhbnNhY3Rpb24uaW1wbC5UcmFuc2FjdGlvbmFsRWRpdGlu Z0RvbWFpbklt
cGwuYWNxdWlyZShUcmFuc2FjdGlvbmFsRWRpdGluZ0RvbWFpbkltcGwuamF2 YTo1MzcpDQoJ
YXQgb3JnLmVjbGlwc2UuZW1mLnRyYW5zYWN0aW9uLmltcGwuVHJhbnNhY3Rp b25hbEVkaXRp
bmdEb21haW5JbXBsLmFjdGl2YXRlKFRyYW5zYWN0aW9uYWxFZGl0aW5nRG9t YWluSW1wbC5q
YXZhOjQ2OSkNCglhdCBvcmcuZWNsaXBzZS5lbWYudHJhbnNhY3Rpb24uaW1w bC5UcmFuc2Fj
dGlvbkltcGwuc3RhcnQoVHJhbnNhY3Rpb25JbXBsLmphdmE6MTg0KQ0KCWF0 IG9yZy5lY2xp
cHNlLmVtZi50cmFuc2FjdGlvbi5pbXBsLlRyYW5zYWN0aW9uYWxFZGl0aW5n RG9tYWluSW1w
bC5zdGFydFRyYW5zYWN0aW9uKFRyYW5zYWN0aW9uYWxFZGl0aW5nRG9tYWlu SW1wbC5qYXZh
OjM4NSkNCglhdCBvcmcuZWNsaXBzZS5lbWYud29ya3NwYWNlLkFic3RyYWN0 RU1GT3BlcmF0
aW9uLmNyZWF0ZVRyYW5zYWN0aW9uKEFic3RyYWN0RU1GT3BlcmF0aW9uLmph dmE6NTQzKQ0K
CWF0IG9yZy5lY2xpcHNlLmVtZi53b3Jrc3BhY2UuQWJzdHJhY3RFTUZPcGVy YXRpb24uZXhl
Y3V0ZShBYnN0cmFjdEVNRk9wZXJhdGlvbi5qYXZhOjE2NikNCglhdCBvcmcu ZWNsaXBzZS5n
bWYucnVudGltZS5kaWFncmFtLnVpLmNvbW1hbmRzLlNlbWFudGljQ3JlYXRl Q29tbWFuZC5k
b0V4ZWN1dGVXaXRoUmVzdWx0KFNlbWFudGljQ3JlYXRlQ29tbWFuZC5qYXZh OjcxKQ0KCWF0
IG9yZy5lY2xpcHNlLmdtZi5ydW50aW1lLmNvbW1vbi5jb3JlLmNvbW1hbmQu QWJzdHJhY3RD
b21tYW5kLmV4ZWN1dGUoQWJzdHJhY3RDb21tYW5kLmphdmE6MTM1KQ0KCWF0 IG9yZy5lY2xp
cHNlLmdtZi5ydW50aW1lLmNvbW1vbi5jb3JlLmNvbW1hbmQuQ29tcG9zaXRl Q29tbWFuZC5k
b0V4ZWN1dGVXaXRoUmVzdWx0KENvbXBvc2l0ZUNvbW1hbmQuamF2YTo0MDMp DQoJYXQgb3Jn
LmVjbGlwc2UuZ21mLnJ1bnRpbWUuY29tbW9uLmNvcmUuY29tbWFuZC5BYnN0 cmFjdENvbW1h
bmQuZXhlY3V0ZShBYnN0cmFjdENvbW1hbmQuamF2YToxMzUpDQoJYXQgb3Jn LmVjbGlwc2Uu
Z21mLnJ1bnRpbWUuY29tbW9uLmNvcmUuY29tbWFuZC5Db21wb3NpdGVDb21t YW5kLmRvRXhl
Y3V0ZVdpdGhSZXN1bHQoQ29tcG9zaXRlQ29tbWFuZC5qYXZhOjQwMykNCglh dCBvcmcuZWNs
aXBzZS5nbWYucnVudGltZS5jb21tb24uY29yZS5jb21tYW5kLkFic3RyYWN0 Q29tbWFuZC5l
eGVjdXRlKEFic3RyYWN0Q29tbWFuZC5qYXZhOjEzNSkNCglhdCBvcmcuZWNs aXBzZS5jb3Jl
LmNvbW1hbmRzLm9wZXJhdGlvbnMuRGVmYXVsdE9wZXJhdGlvbkhpc3Rvcnku ZXhlY3V0ZShE
ZWZhdWx0T3BlcmF0aW9uSGlzdG9yeS5qYXZhOjUxMSkNCgkuLi4gNTggbW9y ZQ0K
--------------070903030304010706070009--
Re: Drag and Drop on a diagram creates EditPart in wrong place [message #227723 is a reply to message #227716] Mon, 27 April 2009 16:22 Go to previous message
Esteban Dugueperoux is currently offline Esteban DugueperouxFriend
Messages: 472
Registered: July 2009
Senior Member
And with the corresponding view of my BusinessModel EObject is well displayed on my GMF diagram, the exception occured on
editPart.getDiagramEditDomain().getDiagramCommandStack().exe cute(createBusinessCmd); on first command execution not on SetValueCommand.


Esteban DUGUEPEROUX a écrit :
> Hi Igor,
>
> Thanks for your reply, I tried your code :
> I have overrided "Command getDropFileCommand(DropObjectsRequest)" method
> in my DiagramDragDropEditPolicy as following :
>
> protected Command getDropFileCommand(DropObjectsRequest dropRequest) {
> Object nextObject = dropRequest.getObjects().get(0);
>
> List<CreateViewRequest.ViewDescriptor> viewDescriptors = new
> ArrayList<CreateViewRequest.ViewDescriptor>();
>
> MDAProjectEditPart editPart = (MDAProjectEditPart) getHost();
> String fileName = (String) nextObject;
> File file = new File(fileName);
> String name = file.getName();
>
> IGraphicalEditPart host = (IGraphicalEditPart) getHost();
> EObject hostElement = host.resolveSemanticElement();
> IElementType elementType = MdaElementTypes.Model_1004;
> CreateElementRequest req = new CreateElementRequest( elementType );
> req.setContainer(hostElement);
> req.setEditingDomain(host.getEditingDomain());
>
> BusinessModel model = MdaFactory.eINSTANCE.createBusinessModel();
> model.setFile(file);
> model.setName(name);
>
> req.setNewElement(model);
> viewDescriptors = new ArrayList();
> viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
> new CreateElementRequestAdapter(req),
> Node.class, null, editPart.getDiagramPreferencesHint()));
> MyDropCommand dropCommand = new MyDropCommand(req, model);
> Command command = createViewsAndArrangeCommand(dropRequest,
> viewDescriptors);
> Command plop = new ICommandProxy(dropCommand).chain(command);
> return plop;
> }
>
> With MyDropCommand.doDefaultElementCreation() returning my previous
> created model EObject from DiagramDragDropEditPolicy.getDropFileCommand()
>
> When testing I get a NPE at
> org.eclipse.gef.editpolicies.ConstrainedLayoutEditPolicy.get ConstraintFor(ConstrainedLayoutEditPolicy.java:204)
>
> cause by
> org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.getDropObjectsCommand()
> which call createViewsAndArrangeCommand()
>
> I don't understand why.
>
>
> Currently I used another mean, I used two first tips from
> http://wiki.eclipse.org/index.php/GMF_Tips
>
> and in my DiagramDragDropEditPolicy.getDropObjectsCommand() I have used
> GMF tips (see attached source file).
>
> When testing I have :
>
> IllegalStateException: Cannot activate read/write transaction in
> read-only transaction context
>
> see attached .log
>
> Thanks.
>
> Igor Klinchin a écrit :
>> Hi Esteban,
>>
>> On Tue, 14 Apr 2009 11:10:52 +0200, Esteban DUGUEPEROUX wrote:
>>
>>> Hi Igor,
>>>
>>> Thanks for you help, now I can create new elements(View with
>>> corresponding model element : CreateViewAndElementRequest)
>>> My code is similar to http://wiki.eclipse.org/index.php/GMF_Tips
>>> (first tip).
>>> But when I dropped a file to my diagram I would like to initialize my
>>> new created element with property values according to my dropped
>>> file. I could chain my first Command resulting of my
>>> CreateViewAndElementRequest with a second command from a SetRequest
>>> but constructor of SetRequest need the model element to change
>>> property then How to fetch created element from my
>>> CreateViewAndElementRequest?
>>
>> I think that you need to create your own command (CreateElementCommand)
>> based on the CreateElementRequest (and create this CreateElementRequest
>> before it also). The command should build the new object and in its
>> doDefaultElementCreation method add the object to the model. It could be
>> done in DiagramDragDropEditPolicy like this:
>>
>> IGraphicalEditPart host = (IGraphicalEditPart) getHost();
>> EObject hostElement = host.resolveSemanticElement();
>>
>> (...)
>>
>> CreateElementRequest req = new CreateElementRequest( elementType );
>> req.setContainmentFeature(...);
>> req.setContainer(hostElement);
>> req.setEditingDomain(host.getEditingDomain());
>> req.setNewElement(<... new object ...>);
>>
>> (...)
>>
>> ArrayList viewDescriptors = new ArrayList();
>> viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
>> <... new object ...>, Node.class, null, preferencesHint));
>>
>> MyDropTypeCommand dropCommand = new MyDropCommand(req);
>> Command command = createViewsAndArrangeCommand(request, viewDescriptors);
>> return new ICommandProxy(dropCommand).chain( command );
>>
>> It seems to me that there are many ways to do it and I am not sure that I
>> have the most efficient one. It was kind of a solution that worked for
>> me.
>>
>>> Also in GMF API, we can see two package with request :
>>>
>>> - org.eclipse.gmf.runtime.emf.type.core.requests
>>> - org.eclipse.gmf.runtime.diagram.ui.requests
>>>
>>> EditPart.getCommand(Request) or in
>>> DiagramDragDropEditPolicy.getCommand(Request) seems to accept only
>>> requests from second package then What are requests from first package?
>>
>> The first one is used in the other command that you will need to
>> implement
>> extending CreateElementCommand in order to construct and add completely
>> new object to the diagram. Here is a constructor for such command that
>> you
>> will need to call to initialize this command:
>>
>> public CreateElementCommand(CreateElementRequest request);
>>
>> This request is from org.eclipse.gmf.runtime.emf.type.core.requests;
>>
>> Basically request in DiagramDragDropEditPolicy.getDropObjectsCommand is
>> from *.diagram.ui.requests. CreateElementRequest for your own command
>> that
>> will build the object is from *.runtime.emf.type.core.requests.
>>
>>
>>
>>> CreateViewAndElementRequest belongs to first package while SetRequest
>>> belongs to second.
>>> But to solve this, we can find in
>>> org.eclipse.gmf.runtime.emf.type.core.commands package a
>>> SetValueCommand which accept a SetRequest in constructor and with
>>> ICommandProxy we can wrap the SetValueCommand to a
>>> org.eclipse.gef.commands.Command.
>>>
>>> This last think is correct?
>>
>> I think that we are talking about similar things.
>>>
>>> Also besides to DnD file, I would like to DnD EObject from a View to
>>> my diagram, principe seem similar but instead of use SetRequest and
>>> SetValueCommand I could use MoveRequest and MoveElementsCommand,
>>> correct?
>>
>> I think that MoveRequest and MoveElementCommand are about moving objects
>> inside a diagram. It is like changing coordinates of a figure on the
>> diagram. I might be wrong in this.
>>
>>> But in my DiagramDragDropEditPolicy, I call
>>> DiagramDragDropEditPolicy.getHostObject() method to fetch model
>>> element to pass my MoveRequest constructor but getHostObject() return
>>> null.
>>> Why this return null in my EditPolicy?
>>
>> It is interesting that I also failed to use MoveElementsCommand with
>> similar problems but I was sure that it is used to move figures inside a
>> diagram. In this sence I explained it in the way that I could not move
>> the
>> figure in DiagramDragDropEditPolicy becuase it does not exist yet. It
>> will
>> be added to the diagram after my command that I construct here (from
>> newly
>> constructed request) will add it to the model and
>> createViewsAndArrangeCommand will create a figure on the diagram. I tried
>> to chain this MoveElementsCommand but with no success.
>>
>> I am sorry that I reply that late, I need to check old posts more
>> often. I
>> hope this discussion will help you to understand better the situation
>> inside d&d. I missed such discussions while I was implementing my d&d and
>> messsage from Alex helped me a lot to dig to the right place.
>>
>> Thank you,
>> Igor
>>
>>
>>> Igor Klinchin a écrit :
>>>> Hi Esteban,
>>>>
>>>> I have getObjectsBeingDropped() method overriden in my
>>>> DiagramDropTargetListener. Here I get
>>>>
>>>> ISelection selection =
>>>> LocalSelectionTransfer.getTransfer().getSelection();
>>>>
>>>> then I check whether all objects are valid (I have objects that
>>>> could be
>>>> dropped on the diagram and others that could be not) and return
>>>> ((IStructuredSelection) selection).toList();
>>>>
>>>> createTargetRequest() just return super.createTargetRequest();
>>>>
>>>> I also have DiagramDragDropEditPolicy with overridden
>>>> getDropCommand(ChangeBoundsRequest request). Here I retrieve objects
>>>> from
>>>> DropObjectsRequest and make a CompoundCommand with a Command for
>>>> each of
>>>> the objects from there. Each command (for individual object) builds new
>>>> object to be dropped (in my case I build totally new object since I dnd
>>>> unrelated stuff like file from file system or object from different
>>>> model
>>>> - you may need to just copy the original object or use it as it is),
>>>> create a command that will insert this object into the model and
>>>> builds a
>>>> composite command like this:
>>>>
>>>> CreateElementRequest req = new CreateElementRequest( elementType );
>>>> MyDropCommand dropCommand = new MyDropCommand(req);
>>>> ArrayList viewDescriptors = new ArrayList();
>>>> viewDescriptors.add(new CreateViewRequest.ViewDescriptor(
>>>> new EObjectAdapter(MyNewObject), Node.class, null,
>>>> preferencesHint));
>>>>
>>>> Command command = createViewsAndArrangeCommand(dropRequest,
>>>> viewDescriptors); if( command != null ) {
>>>> return new ICommandProxy(dropCommand).chain( command );
>>>> }
>>>>
>>>> If you already have your object in you model (like you dnd from view
>>>> that
>>>> displays the same model so that editor already has this object) you may
>>>> want to return command; only - no object needs to be inserted into the
>>>> diagram. Otherwise, return command; will insert an object to the
>>>> diagram
>>>> but not in model.
>>>>
>>>> You can debug this piece so that
>>>> DiagramDragDropEditPolicy.getDropCommand() should return not null
>>>> command
>>>> and viewDescriptors should contain a descriptor of some valid object
>>>> from
>>>> the model.
>>>> I do no know whether you can leave default implementation of
>>>> DiagramDragDropEditPolicy. It seems to me that you can in case you dnd
>>>> objects of the same model. I have different situation, I dnd objects
>>>> unrelated to the model so I had to replace the way how model objects
>>>> are
>>>> constructed. In any case, I think, you should install
>>>> DiagramDragDropEditPolicy into your Diagram implementation. Also it
>>>> might
>>>> be that the problem is with DiagramDropTargetListener.
>>>>
>>>> Igor
>>>>
>>>> On Wed, 08 Apr 2009 17:06:04 +0200, Esteban DUGUEPEROUX wrote:
>>>>
>>>>> Hi Igor,
>>>>>
>>>>> I want to have same feature but from a view. Indeed I want DnD
>>>>> EObject object from one view to my GMF editor I have setted a
>>>>> DiagramDropTargetListener on my DiagramDocumentEditor. This
>>>>> DropTargetListener have a createTargetRequest() creating a
>>>>> DropObjectsRequest. By default createViewsAndArrangeCommand method
>>>>> is called in DiagramDragDropEditPolicy then not needed to create a
>>>>> custom DiagramDragDropEditPolicy. Do you really need a custom
>>>>> DiagramDragDropEditPolicy? Do you do a particular action in
>>>>> handleDrop of your DiagramDropTargetListener ?
>>>>>
>>>>> Can you give me some sample code?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Igor Klinchin a écrit :
>>>>>> Hi Alex,
>>>>>>
>>>>>> Thank you very much for your suggestion. It helped a lot. After I
>>>>>> started
>>>>>> to build my command with createViewsAndArrangeCommand method my
>>>>>> CREATION_ROLE policy installed for Diagram model element started to
>>>>>> receive calls for getCommand method where I can get exact mouse
>>>>>> location
>>>>>> in right coordinates. I apply these coordinates in
>>>>>> getCreateCommand of the
>>>>>> same policy where location is always (-1, -1).
>>>>>> I still do not understand why location gets broken in
>>>>>> getCreateCommand but
>>>>>> at least now I have a way to set correct location. When I create new
>>>>>> element by picking a tool from palette the location is correct here.
>>>>>> Bottom line is that my drag and drops create object right under
>>>>>> the mouse
>>>>>> cursor.
>>>>>>
>>>>>> Igor
>>>>>>
>>>>>> On Tue, 31 Mar 2009 11:05:33 +0000, Alex Shatalin wrote:
>>>>>>
>>>>>>> Hello Igor,
>>>>>>>
>>>>>>> Try calling
>>>>>>> org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramDragD ropEditPolicy.createViewsAndArrangeCommand()
>>>>>>> - at least this method is called by GMf-generated code handling
>>>>>>> shortcuts creation on D&D from ProjectExplorer and it looks like
>>>>>>> an element will be created just below the mouse.
>>>>>>>
>>>>>>> -----------------
>>>>>>> Alex Shatalin
>>
>
Previous Topic:How to stop GMFgen to generate Open and OpenURI
Next Topic:Polygon
Goto Forum:
  


Current Time: Thu Apr 25 05:27:39 GMT 2024

Powered by FUDForum. Page generated in 0.04262 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top