Introducing the Resource Selector in diagram editor

[aneveux]

1/ Introduction We would like ParallelJ to feature a Resource Selector able to set the Type of a Data or the Executable field of a Procedure This ParallelJ Resource Selector should mainly rely on the incubating project named as "Resource Selector". This project has been taken from the former XA Type Selector and brought to the Open Source via Eclipse Labs.

2/ Documents: The main page of this project is: https://github.com/XA-Labs/ResourceSelector

The documentation part is: http://code.google.com/a/eclipselabs.org/p/resource-selector/wiki/Introduction

A tutorial is available here: http://code.google.com/a/eclipselabs.org/p/resource-selector/wiki/FirstSteps

The SVN info are available here: http://code.google.com/a/eclipselabs.org/p/resource-selector/source/checkout

Note: As stated in the help, there is a sample available in the SVN.

3/ Specifications of the ParallelJ Resource Selector: The ParallelJ Resource selector should be able to extract the following specific objects:

any class (.java) implementing the java.lang.Runnable interface any class (.java) implementing the java.util.concurrent.Callable interface any class (.java) annotated with @Program (standing for @org.parallelj.Program) any Program EMF object from within any parallelj diagram files (.parallelj) To this end, the resource selector should have some dedicated "Processors" implemented.

3.1/ The ParallelJ resource selector should invoke the dedicated "Processors" when called from the "Select" button of the Executable field (Procedure and sub-classes Properties View), or when called from a new "Select Executable" contextual menu on a Procedure (or sub-classes) It should also use the provided org.eclipselabs.resourceselector.processor.java.hierarchy processor, focused on the Runnable and Callable interfaces. The selected result should be propagated as its value to the related Executable field.

3.2/ The ParallelJ resource selector should invoke the following provided Java processors:

org.eclipselabs.resourceselector.processor.java org.eclipselabs.resourceselector.processor.java.primitives when called from the "Change Type" of the Data Properties View, or when called from a new "Change Type" contextual menu on a Data. The selected result should be propagated as its value to the related Type field. Kindly proceed with this task.

RE-WORDING EDIT: We propose you carry this task out, split in 2 main steps: 1/ First step would consist in focusing on the Data Type Selector, since it only requires some already contributed Java Resource Processors. This action would be plugged in the Data Type select button.

1.1/ You'll need the Resource Selector installed, by using the following Eclipse update site: http://svn.codespot.com/a/eclipselabs.org/resource-selector/site/ Then, check all items but the 2 uml-related ones.

1.2/ Then you have to add the needed dependency to the designer.properties project. You may take the org.eclipselabs.resourceselector.core.samples project as a model and have a glance at this precise chapter of the First Steps help page: http://code.google.com/a/eclipselabs.org/p/resource-selector/wiki/FirstSteps#Invoking_a_Resource_Selector_with_a_given_processor

You should invoke the Resource Selector, using the following Processors:

org.eclipselabs.resourceselector.processor.java org.eclipselabs.resourceselector.processor.java.primitives 2/ Second step would consist in focusing on the Executable Selector. This action would be plugged in the Executable select button.

2.1/ Such Selector would select the Runnable and Callable-based implementations. This can be achieved by using the org.eclipselabs.resourceselector.processor.java.hierarchy Processor and adding both Runnable and Callable classes to its factories, this way, for instance: ResourceProcessorFactory[] factories = new ResourceProcessorFactory[] { new JavaHierarchyTypeProcessorFactory(Callable.class), new JavaHierarchyTypeProcessorFactory(Runnable.class) };

2.2/ Also this Selector would select the complementary objects:

any class (.java) annotated with @Program any Program EMF object from within any parallelj diagram files (.parallelj) This should be achieved by creating two new Processors, which will be described in a later comment. (to be continued...)

Kindly ignore this very final step, and proceed with the task. PS: You may drop the already created typeselector.* projects from ParallelJ.

Hope to have made it clear ^^ Feel free sharing your concerns and comments about it !

[aneveux]

Following comments are imported from our previous issue tracker:

[aneveux]

Specifications of the ParallelJ Resource Selector:

ODC has created the 3 types of processors in a 3 different projects:

1. JavaTypeProcessor --> This processor extracts all the Java objects any class *.java
2. PrimitiveTypeProcessor --> This processor extracts all primitive values of Java (if needed for the DATA type element model)
3. ModelProcessor --> This processor extracts all parallelj element TYPES EMF model objects from within any *.parallelj diagram files.

Please let us know when the EMF model is selected from the type selector than what should be the qualified name. As of now its just EObject.name

These processor are used by executables of Procedure and its subclasses and also by DATA types respectively as requested.

The code is committed and verified. Please review it and let me know to do the further changes.

I have few queries which are mentioned below; Kindly explain the below lines,

any class (.java) implementing the java.util.concurrent.Callable interface any class (.java) annotated with @Program (standing for @org.parallelj.Program) Please explain what needs to be done? Or is it something I need to change my existing JavaTypeProcessor to support it?

[aneveux]

Thanks for re-worded intake and sharing the resource Selector site. After installing as shown in the attached file, I have done with the following points;

For Data Type select button, I have called the

org.eclipselabs.resourceselector.processor.java Processor and org.eclipselabs.resourceselector.processor.java.primitives Processor For Executable select button, I have called only the

org.eclipselabs.resourceselector.processor.java.hierarchy Processor adding both Runnable and Callable classes to its factories. I have committed the code. Please review it and let me know in case of any changes I have to make, if any.

P.S. : I have dropped the already created typeselector.* projects from ParallelJ except the org.parallelj.designer.typeselector.processor.model. This project was created earlier for any Program EMF object from within any parallelj diagram files (*.parallelj). I haven't integrated this code for the moment. If you suggest than I will integrate it after your review.

[aneveux]

The org.parallelj.designer.typeselector.processor.model project seems indeed promising. Would you integrate it like you're suggestting ? I have yet one request to make: There are still mentions of "UML" things within this project, in some comments or object name. Would you please get rid of them all along ? Thanks a lot.

Concerning the 2nd custom processor, we would like it to process all the java classes and match those who are annotated with @Program. Here is an example of such class: package org.demo6;

import javax.annotation.Generated; import org.parallelj.Program; ...

@Generated("//J") @Program public class Demo { ...

You may want to take some time to find a way of searching a class and looking for its annotations. Moreover we would like this processor to be generic towards the targetted annotation (we wish its annotation criterium settable). This means that we would like to have the value of the targetted annotation set by the calling class, and not the Processor itself.

Hope to have made it clear Please feel free asking me any technical help or complementary information if required.

Thanks a lot !

[aneveux]

I have integrated the model processor code with the extention project. Now the procedures and its subobject's executable field will fetch all the EMF objects present in any file of parallelj extention. Thus, overall the executable field will fetch both EMF based ParallelJ objects as well as Java classes implementing the Runnable and Callable interface.

. Please review it and check if the behavior required by you is similarly achieved. If in case of any modification do let me know so that we can fixed it before next week of Tuesday.

I will start with the custom processor for example @Program on Monday and will let you know if we can achieve it that too before Tuesday, keeping quality at higher priority.

[aneveux]

Hi Again!!

From model processor, once the EMF object is selected the executable Field is displayed as

emfObjectName. Ex: procNAME. Let me know if we need to change its fully qualified name. Also, I have created the custom processor for the @Program annotations. In order to look for the @Program annotation we have to apply runtime dependency toward the runtime project, which should be avoided as discussed with you. So let me know other approach.

[aneveux]

Hello,

Made the changes for the model processor. Removed the unwanted packages and uml resources from the project. As discussed in chat, I have made the search only on the Program EMF object from within any parallelj diagram files (*.parallelj) from the selected project.

Tested and working fine. Please take the full update and delete the olde runtime-Eclipse Application to test the desired changes.

Let me know in case of any issues or changes required.

[aneveux]

Morever, now the fully qualified name of the Program made on the executable field is not the same as mentioned above: procNAME

[aneveux]

There is a small concern about the model processor: It doesn't appear like this processor takes the filtering name field into account.

When the User enters the first characters of the desired object, he's expecting to see a list of matching items. This works well with the Callable and Runnable sub-classes (which are displayed filtered according to the user input), but not the model Programs, which are displayed unfiltered.

Would please look into this concern ?

[aneveux]

I have added the ModelMatcher.java in the model.processor project. Thus from now when the User enters the first characters of the desired object, he will see a list of matching items.

Also, if he enters the package name for the Program like "a.b." than he will see all the Program objects belonging to package "a.b". Example - "a.b.A1" , "a.b.A2" , "a.b.c.A3".

Please review it and let me know if I need to adapt any new change for filtering the data elements for the Program model Object.

[aneveux]

Suggestion- We should add the Program Image will loading the program objects name in the resource selector.

Let me know if I need to commit this suggestion in trunk.

[aneveux]

Thanks a lot for your work and statements. I'm sorry for my late answers on this issue.

First, you're absolutely right, the Program model processor should deal with the fully qualified names.

Also, as stated during our last phone call, adding a Program icon next to each resulting Program object is indeed a good suggestion.

Thanks for taking this in account.

[aneveux]

A pretty concerning issue has been raised: The Runnable-Callable Processor shouldn't fetch the Java Interfaces. This is not due to ParallelJ but to the main Resource Selector project.

Therefore, we will have to adopt a workaround and rewrite a custom Processor based on the actual impementation of the JavaHierarchyTypeProcessor.

The new Processor should avoid the Java Interfaces. You may rely on the JavaHierarchyTypeProcessor code, which is available on the SourceForge of the Resource Selector project. The new Processor could be called JavaExecutableProcessor.

Kindly proceed with this task, and feel free asking any question you may have.

[aneveux]

Also, another smaller issue: If one hits the cancel button on the Resource Selector popup box, then the field is all the same set to a null value. I guess that you should check any null or cancelled return before setting the value of the field.

Would you please look into this ? Thanks a lot.

[aneveux]

For the PART - I : Yes I will introduce the new custom processor for the JavaHierarchyTypeProcessor and remove the older dependency of org.eclipselabs.* from the project.

For the PART - II : Can you describe in details the steps so that I can reproduce it and understand the unwanted behavior occuring.

Is the test similar to the step I have described below:-

Assuming that the Procedure executable field has already some value. If user tries to modify it by clicking on the select button and enters some data in the text field of the resource selector, but than clicks on the cancel button than the existing value gets overridden with the null?

Please Explain!!

[aneveux]

1/ Ok thanks ! By the way, to me, you will still need the dependencies toward the main project of the Resource Selector and the other used Processors.

2/ Yes you're right, my comment lacked of details about the scenario of the bug.

Your scenario is indeed the very one I thought about, except that the User may also use the contextual menu to open the Resource Selector.

Thanks a lot !

[aneveux]

1/ Yes, you are correct, but I was talking to remove the older dependency of org.eclipselabs.resourceselector.processor.java.hierarchy plugin and replace it with our custom processor. Sorry for not mentioning it clearly. And Yes, we still require the main project of the Resource Selector.

2/ the test behavior for that smaller issue which I have described above is not occuring. Please let me know if its reproducible at your end.

[aneveux]

I have integrated the new attached icons in the resource Selector for the annotation classes. For this I had to introduced some new class to achieve it.

Please take the update for review and testing.

[aneveux]

Thanks for your work. Yet, I have two concerns to share:

1/ Since I've experienced it again, let me depict the exact scenario of the raised bug concerning the cancel button of the Select Executable box:

1. Say one has a Procedure
2. Set the executable field of this Procedure by using the Select Executable contextual menu, and selecting any listed executable. The executable field shows within the Procedure box.
3. Save the diagram.
4. Open the Select Executable contextual menu on the Procedure again.
5. Hit cancel without doing anything else.
6. Bug: the executable field is set to a null value I would like to call your attention to the fact that this is apprently bound to the contextual menu only, since the Properties View Select Executable menu won't behave the same way. This bug only occurs when one uses the contextual menu.

2/ The Annotation Processor indeed looks good, but it seems that entering a * won't perform the expected action:

1. Say one has a ParallelJ Program-annotated class named Darjeeling (why not
2. One also has a ParallelJ Diagram with a Program and a Procedure
3. Open the Select Executable menu (from the context of this Procedure or from its Properties View, it doesn't matter)
4. Enter the 'd' letter. This will show the Darjeeling Program-annotated class, along with other various "d-something" items (Callable or Executable implementations, etc...)
5. Delete the letter and enter a wildcard *. The Darjeeling Program-annotated class does not show any longer (no Program-annotated classes will ever show by the way). Whereas the other kinds of items (Callables, Runnables, Diagram Programs) remain correctly listed. Kindly look into these two concerns and share with us the state of your searchings.

[aneveux]

Thanks for the test scenario in detail.

1/ Yes, it is reproducing if one uses the contextual menu. I am looking into this issue and will fix it if found the solution. Once done will let you know.

2/ No, it is not occuring. I followed the same scenario as you have mentioned above. But failed to reproduce it. Its working at my end and Please Find Attached the testDarjeeling.bmp file. Please let me know if I have missed any thing. Any Program-annotated class is showed by the way if entered a wildcard '*'.

Finally, the custom processor for the JavaHierarchy is committed avoiding the unwanted interfaces for both Runnable and Callable classes to its factories. Please review it and let me know for any changes to be done.

Many Thanks,

[aneveux]

Hi Again,

Infact for the Test 1/ such unwanted behaviour is also happening if the user clicks on the "Create Executable" from the contextual menu. Looking into both the issue.

[aneveux]

Hi Again,

I have resolved both the bug for the test/1 and Committed it. Please review it.

I am assigning this jira to you so that you can view my comments. Incase of any new bug found or to reopen, please reassign it to me back

Many Thanks,

[aneveux]

Thanks a lot for your work.

1/ The first issue is indeed fixed.

2/ Considering the 2nd one, I cannot figure out why, but I'm not able to raise the problem any longer (whereas it was raised each time I performed the scenario). So sorry for bothering you with this, I now consider it dismissed.

Thanks.