+1. Cheers, Danushka
On Sat, Jun 29, 2013 at 12:59 AM, Suresh Marru <[email protected]> wrote: > 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 > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > >
