Re: [ease-dev] Script location parsers

[Christian Pontesegger <christian.pontesegger@xxxxxx>]

Hi,

see comments below

On 14.06.2017 11:20, Utsav Oza wrote:

Hello,

1. Since Github parser would require interaction with Github API, we would need a json parser to parse the api responses. As mentioned in Bug 518111 - Add a dependency for gson package, we shouldn't require such bundles as hard dependencies, and should check the presence of bundle at runtime. Unfortunately I am not able to find documentation or example regarding the same (validating the presence of an orbit bundle during runtime) demonstrating a recognized way to perform such checks.

2 possibilities here:
a) check for the availability of the bundle you are looking for. Google will give you plenty of source samples, look for something like this:
    Bundle bundle = Platform.getBundle(pluginID);

b) use the classloader of any class and try to load the class you need dynamically:
    classloader.loadClass("class.name")

version a) is nicer, version b) would be sufficient if it is just 1 class you are looking for.

Remember that you do not need this code to write your whole parser. At compile time your bundle would be available. At runtime you do need to perform the check before you are going to load the parser. Do not load it at all if your bundle is not available. To test it you can use a run configuration where you select all plugins manually and enable/disable the gson plugin.

2. For each remote script, a new IScript instance is created and its location is stored in that instance along with few other attributes. For its location we pass in the raw url (like "https://raw.githubusercontent.com/utsavoza/sample-scripts/master/_javascript_%20Beginner%20Tutorial/03%20Threading/01%20Master.js"), because this location will be used to open the InputStream in order to fetch and detect changes in the script keywords. The issue that arises is that as the script is created and event is posted, the relative path of the script that is generated from its location is (for the above example) "sample-scripts/master/_javascript_%20Beginner%20Tutorial/03%20Threading/01%20Master.js" which isn't fairly accurate as it includes additional hierarchical directory for master branch. Even though the scripts are correctly fetched, they are under master directory inside main project directory (here sample-scripts/master/...) and the same hierarchy is created in Script Explorer View.

We had this topic on this list already if I remember correctly. 2 things here to do:
* first cut off the prefix of the URL using the base location for your repository which you register as script location
* then unescape the URL, which gets rid of all the %20 escape characters (and potentially some others)

3. The location parsers would detect changes in the script keywords with differing (string) sha values that is obtained with each obtained scripts. However, currently the script changes depend on the script timestamp (of long vaue). This would require updation of datatypes in few places in order to accommodate the commit hashes of scripts. This can also be done once we have implemented the parsers. As of now we register the scripts with the current system timestamp. In order to facilitate this change is it appropriate to open a separate bug ?

As stated in a previous thread we can perfectly replace the current long timestamp to some String versionIdentifier to be more generic and ready for hashes. Doing this as a separate topic (and thus a separate bug) would be the way to go. You can mark this bug as a blocker for your github parser implementation bug.


Christian