Hello,
I have created working prototype for both Github and Gerrit location parsers. In this regard I am facing certain doubts:
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. 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.
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
?
