airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <thejaka.am...@gmail.com>
Subject Re:
Date Sat, 08 Jun 2013 15:05:23 GMT
Hi Subho,

Some answers are inline. Its really good you think about following aspects
in advance.

Also dont hesitate to post any question to dev list. Dev list the best
place to get feedback from everyone. I am forwarding this to dev list so
others can also express their views.

Thanks
Amila


On Sat, Jun 8, 2013 at 6:47 AM, Subho Banerjee <subs.zero@gmail.com> wrote:

> Hi,
> I had a few question to ask you.
>
> --->>
>
> I was thinking of having a build system for the web frontend which will
> plugin to the ant build of Airavata. I was thinking of using Yeoman.js to
> handle -
>
> 1. The build - Minify the JS and the CSS. Compile CSS from Compass
> 2. Run the testcases through Grunt script on PhantomJS
> 3. Use Bower to make sure that we always have the latest version of the JS
> and CSS frameworks that we are using.
>
> Here is a link to the Yeoman site - http://yeoman.io/
>
> From what I understand, this none of the packages in this framework has a
> license issue. What I wanted to know is how will this be integrated into
> the ant build. I see that Airavata is using a Jenkins server for CI. So, do
> we make change so that the Jenkins server fetches packages or make the
> build system do it.
>
>
Airavata uses maven build. We do not normally use ant but we may have use
some ant tasks within maven. Also you are correct, we use Jenkins as our
CI. I dont have experience with Yo, Grunt or Bower. But it seems like it is
a specific build tool for Javascript and related front end development. So
I am not so sure how we integrate our maven based build and Yeoman.

But I saw following comment from Addy in [1]

"As Yeoman comes with it’s own end to end stack for scaffolding and
building apps, it removes the need to use Maven or Ant. You should be able
to replace your existing Ant-based build process with it."

I am not sure how much we are prepared to do this (Maybe others can also
comment on this).

My suggestion is following.
Code for web XBaya will reside in a separate module. We can write a script
to invoke Yeoman only for Web XBaya module. Then we can call the script
from maven root pom. Further we need to aggregate reports from Yeoman to
show them in the Jenkins web page. Anyhow we need to experiment and see
whether this works as expected.

[1] http://addyosmani.com/blog/improved-developer-tooling-and-yeoman/


>
>
> --->>
>
> Secondly, when you ship the source code of Airavata, do you also ship the
> source code of the JS/CSS packages along with it, or do you expect the user
> to download the requisite files as he compiles/builds the entire package
>
>
We do not expect user to build airavata from source. So once user download
the package he/she should be able to start and run the product without any
configuration changes (If user needs advance scenarios he/she needs to do
configurations, but basic use cases should work without any
configurations). So we have to modify our build scripts include JS/CSS code
in appropriate places and need to make sure user will be able to start
airavata server and open a browser and go to Web XBaya UI by typing the
appropriate URL.

But for development//debugging purpose users may need to download the
source. In such cases we need to make sure all the sources (including
JS/CSS) code also in the source distribution.


>
>
> --->>
>
> For testing purposes, till Shameera gets a basic JSON API working how do I
> simulate message passing? So what I mean to say is, do I start by jsut
> describing a DAG sort of GUI in HTML and worry about the messages from the
> server later? Thats is what I had proposed initially, but I just wanted
> your opinion.
>
>
I think your proposed approach sounds good. But it is essential you all
come to an agreement about communicating interfaces of each component.


>
>
> ---->>
>
> How will the code contribution be? Will each of us in the master project
> get a separate repo and we will commit to that. And finally the changes
> will be pulled in from each one of those?
>
>
I am not quite sure about this. I will let Suresh comment about this
question.

>
>
> Thanks and Cheers,
> Subho.
>

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