Patching the Project entity as well as the GitHub and Google Code classes to support new, interesting metadata that we want to fetch for the projects.
Due to idiosyncrasies between our 3 supported forges, not all project properties are filled depending on where (what forge) the search is being performed. We discussed this problem yesterday in our meeting and it'll be addressed via other "proxy" mechanisms that are yet to be defined.
GitHub is, unfortunately, the only forge that not only provides more interesting parameters but also the one which provides the data in the more appropriate, easy-to-grab way via its official JSON API. The other forges have to be explored in informal, hack-ish ways being SourceForge the hardest one.
Grabbing data is one of the main tasks in Groundhog and we'll always strive to make it better but for now this branch is the best that can be done without completely change the Groundhog Search APIs, which I don't think we should do now.
Patching the Project entity as well as the GitHub and Google Code classes to support new, interesting metadata that we want to fetch for the projects.
Due to idiosyncrasies between our 3 supported forges, not all project properties are filled depending on where (what forge) the search is being performed. We discussed this problem yesterday in our meeting and it'll be addressed via other "proxy" mechanisms that are yet to be defined.
GitHub is, unfortunately, the only forge that not only provides more interesting parameters but also the one which provides the data in the more appropriate, easy-to-grab way via its official JSON API. The other forges have to be explored in informal, hack-ish ways being SourceForge the hardest one.
Grabbing data is one of the main tasks in Groundhog and we'll always strive to make it better but for now this branch is the best that can be done without completely change the Groundhog Search APIs, which I don't think we should do now.