You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Suresh Marru <sm...@apache.org> on 2013/06/23 14:46:47 UTC

SVN repo for GSOC projects

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


Re: SVN repo for GSOC projects

Posted by Danushka Menikkumbura <da...@gmail.com>.
Hi Vijayendra,

It should ideally go into common module IMO. Then the issue is that we need
to use Airavata client API inside it, which might cause cyclic dependency
clashes. We can have it as a separate module but I can hardly think of any
protocol conversion other than XML <-> JSON.

Cheers,
Danushka


On Tue, Jun 25, 2013 at 12:01 AM, Vijayendra Grampurohit <
vijayendra.sdm@gmail.com> wrote:

> Hi Danushka
>
> This looks fine. But what if we have protocol (XML/JSON protocol conversion
> module)
> as a separate branch and not as a sub module under 1. web-gui
> (xbaya-web-ui.
>
> Regards
> Vijayendra
>
>
> 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 <sm...@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
> > >
> > >
> >
>

Re: SVN repo for GSOC projects

Posted by Vijayendra Grampurohit <vi...@gmail.com>.
Hi Danushka

This looks fine. But what if we have protocol (XML/JSON protocol conversion
module)
as a separate branch and not as a sub module under 1. web-gui (xbaya-web-ui.

Regards
Vijayendra


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 <sm...@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
> >
> >
>

Re: SVN repo for GSOC projects

Posted by Shameera Rathnayaka <sh...@gmail.com>.
Hi Suresh

As I have to work with Airavata backend too, it would be good to have a
branch or scratch area to work on it. It is always provide safe side for my
code.

Thanks,
Shameera.


On Tue, Jun 25, 2013 at 8:05 AM, Shameera Rathnayaka <shameerainfo@gmail.com
> wrote:

> Hi Danushaka,
>
> 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.
>>
>
> +1 , But XML to JSON conversion is not with the front end. it happens in
> the backend(I will provide a diagram to explain this).What I provide is JS
> client API, therefore it would be good to have separate module name
> "client-api"  for this.
>
> Thanks,
> Shameera.
>
>
>
>>
>> Sanchit, Shameera, Subho, Vijayendra and Viknes, what do you think?.
>>
>> Thanks,
>> Danushka
>>
>>
>>
>> On Sun, Jun 23, 2013 at 6:16 PM, Suresh Marru <sm...@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
>> >
>> >
>>
>
>
>
> --
> Best Regards,
> Shameera Rathnayaka.
>
> email: shameera AT apache.org , shameerainfo AT gmail.com
> Blog : http://shameerarathnayaka.blogspot.com/
>



-- 
Best Regards,
Shameera Rathnayaka.

email: shameera AT apache.org , shameerainfo AT gmail.com
Blog : http://shameerarathnayaka.blogspot.com/

Re: SVN repo for GSOC projects

Posted by Shameera Rathnayaka <sh...@gmail.com>.
Hi Danushaka,

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.
>

+1 , But XML to JSON conversion is not with the front end. it happens in
the backend(I will provide a diagram to explain this).What I provide is JS
client API, therefore it would be good to have separate module name
"client-api"  for this.

Thanks,
Shameera.



>
> Sanchit, Shameera, Subho, Vijayendra and Viknes, what do you think?.
>
> Thanks,
> Danushka
>
>
>
> On Sun, Jun 23, 2013 at 6:16 PM, Suresh Marru <sm...@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
> >
> >
>



-- 
Best Regards,
Shameera Rathnayaka.

email: shameera AT apache.org , shameerainfo AT gmail.com
Blog : http://shameerarathnayaka.blogspot.com/

Re: SVN repo for GSOC projects

Posted by Danushka Menikkumbura <da...@gmail.com>.
+1.

Cheers,
Danushka


On Sat, Jun 29, 2013 at 12:59 AM, Suresh Marru <sm...@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 <sm...@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 <su...@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 <sm...@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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>

Re: SVN repo for GSOC projects

Posted by Suresh Marru <sm...@apache.org>.
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 <da...@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 <sm...@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 <su...@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 <sm...@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
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 


Re: SVN repo for GSOC projects

Posted by Danushka Menikkumbura <da...@gmail.com>.
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 <sm...@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 <su...@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 <sm...@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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
>
>

Re: SVN repo for GSOC projects

Posted by Suresh Marru <sm...@apache.org>.
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 <su...@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 <vi...@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 <sm...@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
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 


Re: SVN repo for GSOC projects

Posted by Subho Banerjee <su...@gmail.com>.
@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 <vi...@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 <sm...@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
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

RE: SVN repo for GSOC projects

Posted by Viknes Balasubramanee <vi...@msn.com>.
+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 <sm...@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
> >> > >
> >> > >
> >> >
> >>
> >
> >
>

Re: SVN repo for GSOC projects

Posted by Sanchit Aggarwal <sa...@gmail.com>.
+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 <sm...@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
> >> > >
> >> > >
> >> >
> >>
> >
> >
>

Re: SVN repo for GSOC projects

Posted by Danushka Menikkumbura <da...@gmail.com>.
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 <su...@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 <sm...@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
>> > >
>> > >
>> >
>>
>
>

Re: SVN repo for GSOC projects

Posted by Danushka Menikkumbura <da...@gmail.com>.
+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 <su...@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 <sm...@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
> > >
> > >
> >
>

Re: SVN repo for GSOC projects

Posted by Subho Banerjee <su...@gmail.com>.
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 <sm...@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
> >
> >
>

Re: SVN repo for GSOC projects

Posted by Danushka Menikkumbura <da...@gmail.com>.
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 <sm...@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
>
>