Hello there!

Officially, gsoc 2012 is going to end so, here is a quick update on the work done after mid-term evaluation. There were lots of small but challenging features of which, some of them are worth to mention below:

1. Storing multi authors information : composer.json contains array of authors. So, for storing in the db, I had to create one factory class which handles all these tasks (check the last few words)







2. Categorization : By using this feature, we can categorize out extension in different categories. During extension approval, admin would be responsible for assigning a predefined category to submitted extension.



3. Keywords : composer.json of each extension contains one "keyword" field. by using the keywords and proposed download counter, we can short extensions in most downloaded keywords order.

4. Uploading and showing snapshot of extensions by fetching image URL from composer.json.




5. Generating pakage.json This was the most important feature because without this one, we cannot define our proposed extension.silverstripe.org as composer repository.
        Basically, composer installed in user's app will look into this file for confirmation if requested package is available or not on extension.silverstrip.org repo.

6. Sending mail After submission/approval of extension.

7. Disqus commenting system.




8. Search form  on extension landing page based on name/keywords/category/silverstrip compatibility. I created using scaffolding CMS search.




9. Recently submitted extensions  which later will be shown in showcase/gallery after theme work.




10. Unit test  For important classes. It is not in very good shape now but we will improve them.

11. SVN Repositories : Tested and working fine with SVN repositories.

12. demo site extension.openbees.org

13 : Continuous integration : 

14. Lots of code cleanup took place. as a result, the code written before mid-term is now stable and optimized now.

        I was facing some minor issues (see Issue queue) plus some features still need to be implemented. Few test cases are left after which, they will be completed.


As Thomas Jefferson said:   "When you reach the end of your rope, tie a knot in it and hang on"

Just like that my part is not going to be limited with the gsoc completion. You can still find me hanging around this project.

Thanks !

      So finally after long discussion with some senior guys in silverstripe (thanks to them) now its clear in my mind that what actually I have to do during my project. somehow I have distracted in my first week of coding and went in wrong direction. Hopefully you have read my last blog "Problems with composer" actually those prediction were almost wrong and Andrew shown me right picture about Composer. So what I did in first 2 weeks could be very easily done by using Composer itself.
      But unfortunate thing is that I have lost almost 3 weeks before realizing facts and now I have to finish my job in only 4 weeks before mid-term evaluation dead-line.
      In my Gsoc proposal I have planned to finish following tasks before mid-term evaluation.

➢ Redesign Search page of module.
➢ Redesign detailed modules/widgets download page.
➢ Write/improve algorithm & code for
   (1) Integration of ss.org system with module repositories.
   (2) Automatic creation of detailed module download pages.
   (3) Improving modules packaging ability.
   (4) Handling data of subversion.
   (5) Cron jobs (For automatic updates).
➢ Test with some dummy data.
➢ Document the work.

Now due to lack of time I will focus only on following task.

Pahse-1 : Integration of ss.org system with module repositories and creating cron job for automatic updates (6 Jun to 17 Jun).

1. This task consist integration of silverstripe with module repository, fetching module information using composer class and storing them in database for future use. 
2. For implementing this we will take URL of repository as input from users using simple silverstripe Form. This URL will be pass to one of composer class "VcsRepository" and then we will be able to fetch all the package information from module repository. 
3. For cron job we will create sub-class of build-task and so it will update our database Hourly or Daily basis .
4. write Unit-Test for all these tasks.

Phase-2 : Creating Detailed pages of module (18 Jun to 27 Jun). 

1. Most probably It will be an automated task which will create unpublished pages of modules with information stored in database and a link for download master branch.
2.  writing tests for above.

Phase-3 : Handling data of subversions, creating their packages and integrating with module pages, creating a simple module search page (28 Jun to 9 July)

1. Every module may have different versions available for download handling them and providing a download link on module pages will be primary task for this phase . 
2. composer package has a "getDistType" and "getDistUrl" methods which returns url of packages according to type of branch and creates archives for us so we can get help from composer itself for implementing above task.
3. writing tests for above .

 Documentation of work done in all above phases (10 & 11 July ).

I hope this post will help you to watch my progress. for any query or suggestion please comment on this post or mail me personally.
  
Thanks for your time .


       
  

Hello Guys ,
 It's 3rd week of our project time line and still we are facing some conflicts between two SilverStripe gsoc project ( one is mine and other one is Andrew's) . so lets go through this and give me your feedbacks to overcome these problems .  
our primary task for first week was to fetch modules data from different repository save content of json into database (there is so many useful meta data which will later use on detailed page of modules ).

what I did : created a simple silverstripe form took URL of repo , using this url created clone of that module on my server. fetched composer.json file and content of json stored in database. it also need some finishing as suggested by Ingo (should be independent of repository type and create test for this).

Andrew's suggestion : He suggested that we could use Composer itself for fetching these data.

for implementing Andrew's suggestion I tried following thing --

method 1- 
 use packagist code and create an instant of packagist.org with silverstripe .
Problem :
 packagist code is symfony based and I couldn't find any way to integrate it with silverstripe. even Seldaek (lead developer of composer) himself told me that it is not possible.

method 2-
Use packagist.org for fetching all module data . i.e.
"composer create-project silverstripe/composer-installer testA "
then it will search "silverstripe/composer-installer" project on packagist.org.

Problem : 
1 - Every project should be available on packagist.org . we can pass link to external repository but in my case its not working because many git repositories don't allow reading url directly .
2 - If we are using composer then it is also fetching all the dependent modules and I couldn't find any way to stop this (handling data of those dependent modules simultaneously is very tedious task ) . 

Conclusion :  
1- We only need Composer.json file for getting metadata about modules no matters how it fetched from module so I am not able to understand how it will effect me if I will not use composer for fetching this composer.json
2- According to my research method 2 is working just like my way of  implementation . its sending module name to packagist.org searching the module on packagist.org cloning into my server reading the json file and installing dependencies defined in composer.json file (installing dependencies is not required for my project).
                       so i think we should keep going with my way ?

That is all , may be I am wrong at some point please let me know about it and please give your feedbacks.



 

Hello There ! I have created this blog for coordinating with my mentor and SilverStripe community. I will put weekly time line and project plans very soon .