Hi all, I formatted and cleaned the code and added the licence header. Regarding the naming of the project, I named the project as org.wso2.developerstudio.eclipse.errorreporter for now. And about the packages, I referred to the developer studio plugins projects you have sent me. However as I am still not familiar with the naming conventions for developer studio plugins I temporarily created a couple of packages to group the Java classes. I hope I can do the proper renaming and packaging later with your support.
I created the ErrorInfoCollector class and there all the system information and error related information is fetched. However I couldn't find a method to get the plugin version and I am still working on it. And the error report that I have sent you previously had an attribute called fingerprint and it also contained a set of bundle information. Those two parts I could not understand. So I left them for now. As you suggested, this class can be improved later to collect further information regarding the error. I started with preferences page as well. I created a draft preference page and currently working on improving it. This is the new GitHub link of the project repository. Please refer to this afterwards. Link- https://github.com/nathiesha/org.wso2.developerstudio.eclipse.errorreporter.git Thanks and Regards Nathiesha On Fri, May 13, 2016 at 12:26 PM, Kavith Lokuhewage <[email protected]> wrote: > Hi Nathiesha, > > Please find my inline comments. > > On Wed, May 11, 2016 at 12:10 PM, Nathiesha Maddage < > [email protected]> wrote: > >> Hi all, >> >> Regarding the preference settings, as I have read, the plugins that are >> started early are listed in preferences-general-startup and shutdown page. >> So the user can deselect the plugin from that list and then it will not be >> started once Eclipse starts. Is this what is expected? >> > > No. This is not the expectation. > > Or I can add an option for the user to configure the start up settings of >> the error reporting plugin, in a separate preference page, that I am going >> to develop for the Error Reporting plugin settings. >> > > Yes. This is the expectation. > > >> And regarding the multi status of IStatus, I will look into that and I >> will try to fetch all the previously failed operation information. Here I >> have attached a error report that Eclipse error reporting tool produces. >> Please have a look at the information listed in that report regarding the >> error. As you have mentioned earlier, I will add the previously failed >> operation details if available. Other than previously failed operations and >> the information listed in the attached report , what else need to be added >> to the error report? Or is that information sufficient for the development >> team? >> > > For now, we will keep our focus on this information and give priority to > them. However, there's always chance for improvements. Later, if time > permits, we may focus on the aspects such as attaching the artifacts which > could have caused the issue (with the permission of user), information > about project hierarchy, active editor, perspective etc. (we should analyse > the needs for these further), etc. > > >> >> And thank you for the tips about getting the run time details. That saved >> my time. I will try those. And as you have suggested, it is good to use the >> proper coding standards from the beginning. I will get an idea from the >> example project you have sent me, and I will refactor the code accordingly. >> >> > >> Thanks and regards >> >> Nathiesha >> >> >> >> On Wed, May 11, 2016 at 10:08 AM, Kavith Lokuhewage <[email protected]> >> wrote: >> >>> Hi Nathiesha, >>> >>> Great start! Just some heads up for your next steps. >>> >>> An IStatus instance sometimes could be a multi status instance where you >>> can get other IStatus instances associated with it using the getChildren() >>> method[1]. This simply means that a series of operations failed and >>> information about previously failed operations are also valuable when >>> making the report. >>> >>> There are multiple ways to read java run-time version, the easiest would >>> be to read the system property called "java.runtime.version". >>> >>> Furthermore, org.eclipse.core.runtime.Platform class [2] provides >>> multiple methods to fetch run-time environment information such as OS name, >>> architecture and windowing library etc. It will also be helpful for you >>> fetch additional information about the run-time environment. >>> >>> On a side note, I would suggest that it will be good if you starts >>> coding with the proper coding standards we use, from the beginning. This >>> will reduce the time it takes to refactor the code later, in a great >>> amount. As a start you can refactor the current package hierarchy to a >>> proper package hierarchy we use for developer studio plugins [get an idea >>> from - 3]. >>> >>> I am attaching the license header and eclipse code cleanup and >>> formatting templates for java. >>> Go to Window -> Preferences -> Java-> Code Style >>> 1. Set attached templates as cleanup and formatting templates >>> (next format current classes) >>> 2. Set the contents of license header file as the java file >>> comment template in code templates section. >>> >>> Thanks, >>> Kavith Lokuhewage >>> >>> [1] >>> http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2FIStatus.html >>> [2] >>> http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2FPlatform.html >>> [3] >>> https://github.com/wso2/developer-studio/tree/master/plugins/org.wso2.developerstudio.eclipse.updater >>> >>> >>> >>> On Wed, May 11, 2016 at 9:25 AM, Nathiesha Maddage < >>> [email protected]> wrote: >>> >>>> Hi all, >>>> >>>> I created a git hub repository, so the project progress can easily be >>>> tracked. >>>> >>>> I could start up the plugin when the IDE starts up, by implementing >>>> Istartup interface. I tested it as well. Then I created a log listener >>>> class and attached that to the platform log, so any error is notified. >>>> The next task is to filter the Dev studio plugin errors out of them. >>>> For testing purposes, currently my code filters out the errors caused >>>> by org.eclipse.core.runtime, and that seem to work fine. I created a very >>>> basic dialog to notify the error, which will be triggered when an error >>>> occurs. I will further improve the UI later. >>>> And currently I am working on collecting the information regarding the >>>> error, that need to be included in the report. Certain information like >>>> plugin id, error message and severity can be easily obtained by the Istatus >>>> object, and now I am searching for ways to fetch the other information like >>>> java version, plugin version, osgi and bundle related information. >>>> >>>> GitHub Link- https://github.com/nathiesha/ErrorReportingTool.git >>>> >>>> >>>> Regards >>>> >>>> Nathiesha >>>> >>>> On Thu, May 5, 2016 at 6:39 PM, Nathiesha Maddage < >>>> [email protected]> wrote: >>>> >>>>> Hi all, >>>>> >>>>> This is the summary of the facts we discussed during the chat. >>>>> >>>>> >>>>> - Original project proposal was discussed and it was confirmed >>>>> that a new plugin would be developed for developer studio to report >>>>> errors, >>>>> that would have similar functionalities like code recommenders error >>>>> reporting tool. >>>>> >>>>> >>>>> - Certain suggestions were proposed for the original project >>>>> proposal. >>>>> >>>>> >>>>> 1. Instead of using an xml file to store user preferences, a >>>>> separate preference page was suggested. >>>>> 2. For a first time user, a dialog box to get the user input was >>>>> suggested to be develop. The user given values for this dialog box >>>>> would be >>>>> stored in the preference page as well so that user can change those >>>>> values >>>>> later on using the preference page. >>>>> 3. To get the information about the error and the error stack, the >>>>> original idea was to read the log file and fetch the information. >>>>> However >>>>> it was suggested to make use the IStatus object instead, to get the >>>>> error >>>>> related data as it provided methods to fetch those data. >>>>> 4. The plugin should only report the errors that is concerned with >>>>> the developer studio. So as the first step, it was suggested to track >>>>> all >>>>> the errors caused by the developer studio plugin. This is to be >>>>> implemented >>>>> by listening to the error log of the dev studio plugin only. Once this >>>>> task >>>>> is accomplished, I was advised to implement a mechanism to filter all >>>>> the >>>>> other errors as well and find and any errors that has any connection >>>>> with >>>>> the developer studio and to report them as well. >>>>> >>>>> >>>>> >>>>> - I had an issue about registering to the error event. That you >>>>> clarified by suggesting to do the initialization in the start method >>>>> of the >>>>> BundleActivator implemented plugin class. And suggested me to try >>>>> changing >>>>> the start up behavior of the plugin from the default lazy >>>>> initialization >>>>> method into some different method in the manifest file of the plugin. >>>>> >>>>> >>>>> - I was asked to get started with coding, and to maintain a >>>>> git-hub repository, so you can view and comment on the parts I have >>>>> done so >>>>> far. >>>>> >>>>> >>>>> - I was also asked to get started with the error capturing part >>>>> first as it is of highest priority, and then to focus on the UI and >>>>> connecting with Jira. >>>>> >>>>> >>>>> - To track the progress of the project, a milestone plan was asked >>>>> to be prepared on daily basis. >>>>> >>>>> >>>>> - It was discussed to arrange the next meeting/call in another two >>>>> weeks time. >>>>> >>>>> >>>>> >>>>> Please point out if I have missed any important fact in our >>>>> discussion. >>>>> I am currently preparing the milestone plan. I will send it soon. >>>>> >>>>> Regards >>>>> >>>>> Nathiesha >>>>> >>>>> >>>> >>> >>> >>> -- >>> *Kavith Lokuhewage* >>> Software Engineer >>> WSO2 Inc. - http://wso2.com >>> lean . enterprise . middleware >>> Mobile - +9477-9-145-123 | +9471-455-6-401 >>> Linkedin <http://www.linkedin.com/pub/kavith-lokuhewage/49/473/419> >>> Twitter <https://twitter.com/KavithThiranga> >>> >> >> > > Thanks, > -- > *Kavith Lokuhewage* > Software Engineer > WSO2 Inc. - http://wso2.com > lean . enterprise . middleware > Mobile - +9477-9-145-123 | +9471-455-6-401 > Linkedin <http://www.linkedin.com/pub/kavith-lokuhewage/49/473/419> > Twitter <https://twitter.com/KavithThiranga> >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
