vazexqi / codingspectator Goto Github PK

This provides more context to the descriptor and allows us reason about the refactoring that was performed.

Refactorings are initialized with an ICompilationUnit. For capturing the snippets however, an ICompilationUnit is not the best representation.

We want to use an ASTNode instead. To grab an ASTNode from an ICompilationUnit we use
RefactoringASTParser.parseWithASTProvider(fCUnit, true, new NullProgressMonitor()). This method was called in the CheckInitialConditions method of ExtractMethodRefactoring.

This refactoring accounts for about 0.1% of the invocations of refactorings in the UDC data.

Currently when we try to install the plug-in using the update-site feature, Eclipse reports the following conflicts:

Cannot complete the install because of a conflicting dependency.
  Software being installed: Eclipse Watcher 1.0.0.201009271905 (edu.illinois.eclipsewatcher.feature.feature.group 1.0.0.201009271905)
  Software currently installed: Eclipse for RCP and RAP Developers 1.3.1.20100916-1202 (epp.package.rcp 1.3.1.20100916-1202)
  Only one of the following can be installed at once: 
    Java Development Tools UI 3.6.1.r361_v20100825-0800 (org.eclipse.jdt.ui 3.6.1.r361_v20100825-0800)
    Java Development Tools UI 3.6.0.v20100602-1600 (org.eclipse.jdt.ui 3.6.0.v20100602-1600)
    Java Development Tools UI 3.6.0.201009271905 (org.eclipse.jdt.ui 3.6.0.201009271905)
  Cannot satisfy dependency:
    From: Eclipse Watcher 1.0.0.201009271905 (edu.illinois.eclipsewatcher.feature.feature.group 1.0.0.201009271905)
    To: org.eclipse.jdt.ui [3.6.0.201009271905]
  Cannot satisfy dependency:
    From: Eclipse for RCP and RAP Developers 1.3.1.20100916-1202 (epp.package.rcp 1.3.1.20100916-1202)
    To: org.eclipse.epp.package.rcp.feature.feature.group [1.3.1.20100916-1202]
  Cannot satisfy dependency:
    From: EPP RCP/RAP Feature 1.3.1.20100916-1202 (org.eclipse.epp.package.rcp.feature.feature.group 1.3.1.20100916-1202)
    To: org.eclipse.jdt.feature.group 3.6.0
  Cannot satisfy dependency:
    From: Eclipse Java Development Tools 3.6.0.v20100526-0800-7z8XFUJFMTfCWGoVuHImpms9H155 (org.eclipse.jdt.feature.group 3.6.0.v20100526-0800-7z8XFUJFMTfCWGoVuHImpms9H155)
    To: org.eclipse.jdt.ui [3.6.0.v20100602-1600]
  Cannot satisfy dependency:
    From: Eclipse Java Development Tools 3.6.1.r361_v20100714-0800-7z8XFUSFLFlmgLc5z-Bvrt8-HVkH (org.eclipse.jdt.feature.group 3.6.1.r361_v20100714-0800-7z8XFUSFLFlmgLc5z-Bvrt8-HVkH)
    To: org.eclipse.jdt.ui [3.6.1.r361_v20100825-0800]

The conflicts come from the JDT UI and LTK plug-ins since we are using our modified version.

There is a current limitation of the Eclipse platform that prohibits us from installing our custom versions of the JDT and LTK plug-ins. Basically, the p2 provisioning manager checks the version number and if it does not match it will not install it.

Here are the exact errors for JDT:

Cannot complete the install because of a conflicting dependency.
  Software being installed: Eclipse Watcher 1.0.0.201009281425 (edu.illinois.eclipsewatcher.feature.feature.group 1.0.0.201009281425)
  Software currently installed: Eclipse for RCP and RAP Developers 1.3.1.20100916-1202 (epp.package.rcp 1.3.1.20100916-1202)
  Only one of the following can be installed at once: 
    Java Development Tools UI 3.6.1.r361_v20100825-0800 (org.eclipse.jdt.ui 3.6.1.r361_v20100825-0800)
    Java Development Tools UI 3.9.0.201009281425 (org.eclipse.jdt.ui 3.9.0.201009281425)
  Cannot satisfy dependency:
    From: Eclipse Watcher 1.0.0.201009281425 (edu.illinois.eclipsewatcher.feature.feature.group 1.0.0.201009281425)
    To: org.eclipse.jdt.ui [3.9.0.201009281425]
  Cannot satisfy dependency:
    From: Eclipse for RCP and RAP Developers 1.3.1.20100916-1202 (epp.package.rcp 1.3.1.20100916-1202)
    To: org.eclipse.epp.package.rcp.feature.feature.group [1.3.1.20100916-1202]
  Cannot satisfy dependency:
    From: EPP RCP/RAP Feature 1.3.1.20100916-1202 (org.eclipse.epp.package.rcp.feature.feature.group 1.3.1.20100916-1202)
    To: org.eclipse.jdt.feature.group 3.6.0
  Cannot satisfy dependency:
    From: Eclipse Java Development Tools 3.6.1.r361_v20100714-0800-7z8XFUSFLFlmgLc5z-Bvrt8-HVkH (org.eclipse.jdt.feature.group 3.6.1.r361_v20100714-0800-7z8XFUSFLFlmgLc5z-Bvrt8-HVkH)
    To: org.eclipse.jdt.ui [3.6.1.r361_v20100825-0800]

and here are the errors for the LTK:

Cannot complete the install because of a conflicting dependency.
  Software being installed: Eclipse Watcher 1.0.0.201009281557 (edu.illinois.eclipsewatcher.feature.feature.group 1.0.0.201009281557)
  Software currently installed: Eclipse for RCP and RAP Developers 1.3.1.20100916-1202 (epp.package.rcp 1.3.1.20100916-1202)
  Only one of the following can be installed at once: 
    Refactoring UI 3.5.0.v20100526-0800 (org.eclipse.ltk.ui.refactoring 3.5.0.v20100526-0800)
    Refactoring UI 3.5.0.201009281557 (org.eclipse.ltk.ui.refactoring 3.5.0.201009281557)
  Cannot satisfy dependency:
    From: Eclipse Watcher 1.0.0.201009281557 (edu.illinois.eclipsewatcher.feature.feature.group 1.0.0.201009281557)
    To: org.eclipse.ltk.ui.refactoring [3.5.0.201009281557]
  Cannot satisfy dependency:
    From: Eclipse for RCP and RAP Developers 1.3.1.20100916-1202 (epp.package.rcp 1.3.1.20100916-1202)
    To: org.eclipse.epp.package.rcp.feature.feature.group [1.3.1.20100916-1202]
  Cannot satisfy dependency:
    From: EPP RCP/RAP Feature 1.3.1.20100916-1202 (org.eclipse.epp.package.rcp.feature.feature.group 1.3.1.20100916-1202)
    To: org.eclipse.platform.feature.group 3.6.0
  Cannot satisfy dependency:
    From: Eclipse Platform 3.6.1.r361_v20100909-9gF78GrkFqw7GrsZnvz0JWNTeb6fue6896L (org.eclipse.platform.feature.group 3.6.1.r361_v20100909-9gF78GrkFqw7GrsZnvz0JWNTeb6fue6896L)
    To: org.eclipse.ltk.ui.refactoring [3.5.0.v20100526-0800]

The following projects are unused.

org.apache.*
org.eclipse.epp.usagedata.*

The following page might be helpful to resolve this issue.

http://help.github.com/removing-sensitive-data/

This bug is present in 6d3ef3a

When the user first starts up the workspace, our Eclipse Watcher uploader kicks in and tries to upload something. However, since this is the first time that we are doing it, it seems that the UUID is null.

Therefore, on the initial commit and checkout, Eclipse Watcher actually pulls whatever is from http://subversion.assembla.com/svn/ganje/Experiment/nchen/ instead of http://subversion.assembla.com/svn/ganje/Experiment/nchen/<unique_UUID> since no UUID has been generated.

Suggested resolution: check why isn't UUID is null?

We might want to capture the sequence of events that happens when a user previews e.g.

Preview -> Back -> OK
Preview -> Cancel
Preview -> OK

Parts of the class edu.illinois.refactoringwatcher.monitor.ui.AuthenticationPrompter that manage the secure storage could be extracted and moved to a UI independent class. This refactoring removes the big class and separates the UI from domain better.

If we popup the username/password dialog and the user provides the wrong information or cancels it, we show the dialog again. But, if the user checks the save password option, he'll be shown a second dialog box to provide a master password. If the user cancels the second dialog, we no longer ask him for entering authentication information and no such information we'll be saved either.

See http://github.com/vazexqi/RefactoringWatcher/commit/746fb83697dd30e95ba773cb4e1b2bcd60243417#diff-1

Requires extracting the lookup functionality from AuthenticationPrompter.

Every version of our plug-in might record different events. So, we need to tell the version of our plug-in using which the events have been captured.

One way to associate the version number to the collected data is to store the version number as part of the collected data. This results in some duplication as we have to record this information whether or not the user has upgraded his/her plug-in. Besides, it makes it harder for us to distinguish the data collected by different versions of our plug-in, as we have to examine the version number encoded in every version of the collected data to find out when it changes.

A better way to keep track of the version of the plug-in used to log the events is to reorganize the directory structure as one of the following.

1. <RepositoryLocation>/<User>/<Workspace ID>/<Watcher Version>
2. <RepositoryLocation>/<User>/<Watcher Version>/<Workspace ID>
3. <RepositoryLocation>/<Watcher Version>/<User>/<Workspace ID>

The above list of directory structures is not extensive. But, I kind of prefer the first directory structure, because it matches the ownership relationships. That is, a user has multiple workspaces, and every workspace gets monitored by different versions of our plug-in during a period of time. Moreover, it sorts the directories based on their lifetime. That is, users usually keep using a workspace longer than a specific version of our plug-in. This property limits the scope of changes to inner most directories.

We could just make the update URL point to somewhere in our git repository.

Right now the file stores all the information into a the comment attribute in the XML node. This is very messy and makes it hard to parse.

We should create our own nodes.

See http://pages.github.com/ for details.

We can then query the ASTNode to get its surrounding nodes and get the text representation i.e. the code snippet.

SVNKit provides a specialized exception when the user has entered a wrong username/password. We can use this to help prompt the user again for that info in the dialog box.

This is under the same package as Inline Method, Extract Method refactoring but the structure appears to be a bit different. We need to see if the WatchedRefactoring methods that we are using can work for this case.

Currently, we upload the data every time Eclipse starts up. As a result, we ask for users username/password or master password every time the Eclipse starts up. This could quickly become annoying. We need to ask for authentication information less frequently. For example, we could set a policy to upload data at most once a day or on every nth startup of Eclipse.

We need to separate the code that belongs to the UI from the underlying domain logic. We'll dedicate a package to the UI.

If the user doesn't have versions of LTK and JDT that our patches expect, Eclipse ignores the patches and installs the rest of the plugins. This is an undesirable behavior because our plugins won't collect anything if the patches don't work.

We did the following experiment to see what happens if the version of the existing plugin doesn't match the one that the patch requires. We installed the feature patch on an instance of Eclipse that didn't contain the exact version. The installation went through without giving any error messages. And, the installation details showed that the feature patches were installed. But, our versions of JDT and LTK plug-in didn't show up in the installed plug-ins list. Therefore, even though Eclipse was telling us that the installation had completed successfully, it didn't install our versions of LTK and JDT plug-ins. This is a dangerous behavior for us, because the user won't have any idea that our feature hasn't been completely installed.

When a user enters a wrong username/password but chooses to save the password, the system continues to ask the user to enter master password. Meanwhile, it prompts the username/password again to get the correct username password. This results in two modal dialogs shown to the user at the same time, which is annoying to handle.

One way to resolve the problem is to postpone the persistence of the authentication information until they are proven to be correct.

We want to give the user the option to manually upload the recorded data to the repository. This will be done in a similar manner to what UDC does: having an explicit button in the dialog box.

This should be a simple test of how good our current infrastructure is since this is very similar to the other two refactorings that we have modified: Extract Method and Inline Method refactorings.

Commit 60c6dcb doesn't resolve the issue #11 completely. If the user enters a wrong username/password, it doesn't tell the user that the entered username/password is wrong. Instead, it prompts the user again. We should fix it by showing the user an appropriate dialog that informs him/her of wrong username/password.

Inline Temp Refactoring has an additional check that it performs before it pops-up the Refactoring Wizard. This check actually detects if a temporary variable is assigned to more than once (like in a loop) and disallows the refactoring from happening.

Since this check happens before the RefactoringWizard, we cannot capture it using our current method.

Like Issue #22, I suspect that generic refactorings like rename would also have a different infrastructure and require us to use a different approach for capturing the refactoring descriptors.

In particular, for certain operations, the refactoring dialog doesn't even appear. Some can be done in-place in the editor itself. Therefore we need to see how to hook into that system.

If the user saves his username/password that we use to upload his Eclipse logs, every time we try to upload the data as the Eclipse starts up, he will be asked to enter his master password for the Eclipse secure storage. However, the generic dialog that asks for the master password doesn't tell the user why it needs the master password. So, the user might just cancel the dialog, because he doesn't know why he has to enter a master password. We have to find a way to communicate to the user why we need his master password.

The Pull Up Refactoring is worth investigating because its structure is different from the other two refactorings that we have seen: Extract Method and Inline Method.

Pull Up Refactoring is a ProcessorBasedRefactoring instead of a regular Refactoring instance. Ideally it will allow other participants to hook into the refactoring process. However, from examining the code, this decision might have been an overengineering decision since there are currently no participants yet.

More importantly, this Pull Up Refactoring is different from other refactorings because it it is based on selecting elements instead of text in the editor.

I suspect that all refactorings in the package org.eclipse.jdt.internal.corext.refactoring.structure are of this genre.

So currently there are two classes of refactorings: text-selection and element-selection (through some wizard).

Right now Submitter has redundant information. It takes the username through its constructor but it also accesses the username through the preference store.

Resolution:

1. netid field in the preference page has to either removed or disabled since this information has to be set when the user is asked for authentication (through the Eclipse Secure Storage facility).

Here is the error that we get:

An error occurred while collecting items to be installed
session context was:(profile=epp.package.rcp, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
Problems downloading artifact: osgi.bundle,org.tmatesoft.svn_1.3.4.eclipse,1.0.0.
Error reading signed content:/var/folders/DF/DFH4kIjaFAyM1zkj+iHmyU+++TI/-Tmp-/signatureFile4035969860381721975.jar
An error occurred while processing the signatures for the file: /var/folders/DF/DFH4kIjaFAyM1zkj+iHmyU+++TI/-Tmp-/signatureFile4035969860381721975.jar

We want to give the user the option to manually upload the recorded data to the repository. This will be done in a similar manner to what UDC does: having an explicit button in the dialog box.

Closed in 1ca326e

Right now, our feature patches target specific versions of JDT and LTK on the target platform. Therefore, these patches are very brittle. Andrew Niefer propose a solution that requires a manual change to one of the generated metadata files. Specifically, he suggests to replace the exact target version by a range of versions in the XML file contained in the content.jar of the update site project.

Need to check what this refactoring does since I am not familiar with this refactoring (or how to invoke it).

There is an error in the way that we get the text for the selected element.