Hi Danushka, Anything you patch to the trunk, I would suggest to directly to contribute to the trunk itself. Since we all are in active development phase, you should get enough screams is something breaks.
The new gsoc sandbox I suggested is for components which are not currently in trunk, like the new web components. Towards the end of gsoc, we need to merge the sandbox also with main code base. If your contributions naturally belong to main code base, start sending patches. Other way to look at this is: * if you are in a exploratory phase, you certainly want to keep that code in gsoc-sandbox. * if you have a well-tested piece which does not break the builds, it can directly go to trunk. Suresh On Jun 28, 2013, at 3:17 PM, Danushka Menikkumbura <[email protected]> wrote: > Hi Suresh, > > We have discussed about the layout on this thread but not sure if we have > deviated (naturally) from it while working. > > I wonder if we should clone the trunk and submit patches against it? I mean > gsoc2013 branch or something?. > > Thanks, > Danushka > > > On Sat, Jun 29, 2013 at 12:27 AM, Suresh Marru <[email protected]> wrote: > >> Hi All, >> >> Very nice to see all of you so actively sharing information. I think the >> we are only missing code reviews others you all are doing great. >> >> Can we agree upon these suggested repo structure? Can any one please post >> the final agreed layout? I will create the repo and you guys can create >> JIRA's and start submitting patches. >> >> An important aspect of GSoC is to learn about open source contributions >> and the apache way is to do it through patches and review board code >> reviews. Few of you already have lot of experience with it, it will be >> great to others to follow suite. >> >> Suresh >> >> On Jun 25, 2013, at 3:48 PM, Subho Banerjee <[email protected]> wrote: >> >>> @Viknes: Yup... thats what my plan is. AngularJS - Bootstrap - jsPlumb. I >>> am currently implementing the AngularJS Models for the Workflow >> composition >>> process. >>> >>> @Dhanushka: Any third party JS library goes into the vendor folder (thats >>> what the HTML boilerplate people say). >>> The deployment structure is a bit different, currently I am looking at >>> Grunt to do the minification of CSS and JS as well as compile >> SASS/Compass >>> that comes from the Bootstrap project. This will be integrated into the >>> Maven build to produce (versions of) the webapp that is optimized for >>> browsers and screen sizes, we can probably enable the server to serve >>> different versions depending on the source of the request. >>> >>> >>> On Tue, Jun 25, 2013 at 11:08 PM, Viknes Balasubramanee <[email protected] >>> wrote: >>> >>>> +1 for the Boilerplate structure. >>>> >>>> Speaking of sharing JS libraries, I think AngularJS[1] would be a >> perfect >>>> fit as you can define services and modules and share them between >> different >>>> webapps easily. >>>> It has a sharp learning curve, but once you get used to it, it should be >>>> fun to code with. >>>> >>>> Also I suggest we use Twitter Bootstrap[2] for the look and feel. >>>> >>>> [1] http://www.angularjs.org/ >>>> [2] http://twitter.github.io/bootstrap/index.html >>>> >>>> Thanks >>>> Viknes >>>> >>>> -----Original Message----- >>>> From: Sanchit Aggarwal [mailto:[email protected]] >>>> Sent: Tuesday, June 25, 2013 10:55 AM >>>> To: [email protected] >>>> Subject: Re: SVN repo for GSOC projects >>>> >>>> +1 >>>> >>>> Danushka , >>>> we can have a utilities folder under the JS folder itself and from there >>>> the shared JS libraries can be used. >>>> >>>> Regards >>>> Sanchit Aggarwal >>>> MS Research (Computer Science) >>>> Center for Visual Information Technology IIIT Hyderabad, Gachibowli >>>> Contact - 9581417330 >>>> >>>> >>>> >>>> On Tue, Jun 25, 2013 at 11:49 AM, Danushka Menikkumbura < >>>> [email protected]> wrote: >>>> >>>>> Maybe it is a deployment model is it? >>>>> >>>>> >>>>> On Tue, Jun 25, 2013 at 11:46 AM, Danushka Menikkumbura < >>>>> [email protected]> wrote: >>>>> >>>>>> +1. >>>>>> >>>>>> How would you use shared JS libraries in this boilerplate BTW?. >>>>>> >>>>>> Cheers, >>>>>> Danushka >>>>>> >>>>>> >>>>>> On Tue, Jun 25, 2013 at 11:36 AM, Subho Banerjee >>>>>> <[email protected] >>>>>> wrote: >>>>>> >>>>>>> I would like to suggest a slightly different layout. Particularly >>>>> because >>>>>>> the logic for the UI for Workflow composition and Workflow >>>>>>> composition itself in HTML are not seperate. Also, I am following >>>>>>> the HTML5 Boilerplate to structure my front end code[1], so this >>>>>>> means that code which I write for the workflow composition UI is >>>>>>> structured as follows - >>>>>>> >>>>>>> /:. >>>>>>> ├───index.html >>>>>>> ├───css >>>>>>> └───vendor >>>>>>> ├───doc >>>>>>> ├───img >>>>>>> └───js >>>>>>> ├───vendor >>>>>>> ├───model >>>>>>> └───controlers >>>>>>> >>>>>>> Now, the js folder contains all the front end logic for the UI as >>>>>>> well >>>>> as >>>>>>> workflow composition. I would suggest that we follow this structure >>>>>>> and not further subdivide the web UI module. In which case, we can >>>>>>> reuse objects in between the various web-ui sub-projects. >>>>>>> >>>>>>> Cheers, >>>>>>> Subho. >>>>>>> >>>>>>> >>>>>>> [1] http://html5boilerplate.com/ >>>>>>> >>>>>>> >>>>>>> On Mon, Jun 24, 2013 at 11:47 PM, Danushka Menikkumbura < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Suresh, >>>>>>>> >>>>>>>> I think we need to have the following structure. >>>>>>>> >>>>>>>> 1. web-gui (xbaya-web-ui?) - The Web UI would be a top-level >>>>>>>> module, >>>>>>> under >>>>>>>> which we may have the following sub modules. >>>>>>>> >>>>>>>> - ui (Widgets, graph, canvases, etc) >>>>>>>> - workflow (Workflow composition, execution) >>>>>>>> - monitor (Workflow monitoring) >>>>>>>> - protocol (XML/JSON protocol conversion module) >>>>>>>> >>>>>>>> 2. ws-messenger.client.protocol.amqp - AMQP client API bits >>>>>>>> >>>>>>>> 3. xbaya-gui.ui - AMQP configuration + monitoring. >>>>>>>> >>>>>>>> Sanchit, Shameera, Subho, Vijayendra and Viknes, what do you think?. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Danushka >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Jun 23, 2013 at 6:16 PM, Suresh Marru <[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please discuss how should we structure the SVN repo for gsoc >>>>> projects? >>>>>>>>> certainly not by student since every one is contributing to >>>>>>>>> master >>>>>>>> project. >>>>>>>>> So may be the functional components? >>>>>>>>> >>>>>>>>> I created a sandbox area, please discuss how individual modules >>>>>>> should be >>>>>>>>> organized and please create JIRA's and submit patches to this >>>> repo. >>>>>>>>> >>>>>>>>> https://svn.apache.org/repos/asf/airavata/sandbox/gsoc2013 >>>>>>>>> >>>>>>>>> Suresh >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >> >>
