airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <danushka.menikkumb...@gmail.com>
Subject Re: SVN repo for GSOC projects
Date Fri, 28 Jun 2013 19:40:03 GMT
+1.

Cheers,
Danushka


On Sat, Jun 29, 2013 at 12:59 AM, Suresh Marru <smarru@apache.org> 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 <
> danushka.menikkumbura@gmail.com> 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 <smarru@apache.org>
> 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 <subs.zero@gmail.com>
> 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 <
> viknesb@msn.com
> >>> 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:sanchitagarwal108@gmail.com]
> >>>> Sent: Tuesday, June 25, 2013 10:55 AM
> >>>> To: dev@airavata.apache.org
> >>>> 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 <
> >>>> danushka.menikkumbura@gmail.com> wrote:
> >>>>
> >>>>> Maybe it is a deployment model is it?
> >>>>>
> >>>>>
> >>>>> On Tue, Jun 25, 2013 at 11:46 AM, Danushka Menikkumbura <
> >>>>> danushka.menikkumbura@gmail.com> 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
> >>>>>> <subs.zero@gmail.com
> >>>>>> 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
<
> >>>>>>> danushka.menikkumbura@gmail.com> 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 <smarru@apache.org>
> >>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message