Hi Suresh, According to the new structure, where do you plan to have server implementation ? Is it under org.apache.airavata.api.server.handler of airavata-api-server ?
Thanks.. Chathuri On Mon, Feb 10, 2014 at 3:18 PM, Shameera Rathnayaka <[email protected] > wrote: > Hi Suresh, > > I am more than happy bring JS-API again to consideration and continue > integration with airavata code base. Let's have a discussion once you > ready. > > Thanks, > Shameera. > > > On Tue, Feb 11, 2014 at 1:13 AM, Suresh Marru <[email protected]> wrote: > >> Thanks for catching it Shameera. I realized that mistake after wasting >> some time this morning. Good to know we have more eyes to look at the repos. >> >> I have specific question on JS-API relevance to all of the thrift >> integration efforts, but I will wait for a couple more days and ask you >> more preciously. But it will be great to get your insights on this. >> >> Suresh >> >> On Feb 10, 2014, at 2:24 PM, Shameera Rathnayaka <[email protected]> >> wrote: >> >> > Hi Suresh, >> > >> > There is an issue with >> airavata-api/airavata-client-sdks/java-client-samples/pom.xml, It seems >> parent artifactId should be changed to "airavata-client-sdks". If you need >> to isolate the airavata-api(hope that is what you mean by "they are not >> integrated) from main build as you are refactoring that module, better way >> to do that is comment out airavata-api module from root pom.xml . We can >> uncomment once you finish your works. >> > >> > Thanks, >> > Shameera. >> > >> > >> > On Mon, Feb 10, 2014 at 8:51 PM, Suresh Marru <[email protected]> >> wrote: >> > Hi All, >> > >> > I see that most of current activity is in CPI's within the modules >> directory. Can I use this window of time and request for a lock on the >> airavata-api directory for couple of days? I want to use this time to >> liberally organize the client and server packages. I just committed a mock >> of Airavata API client and server and I learnt lot of do's and don'ts. >> Changes to airavata-api should not impact any of the development within >> modules (as of now, since they are not integrated). My goal is to >> accomplish the following: >> > >> > * A client distribution which has no transitive dependencies to any >> server side jars other than the model, logging and client side security. >> > * A simple client distribution at the same time have it modularized so >> any changes to thrift interfaces and re-generation of stubs/skeltons is >> seamless >> > * A server deployment package and a shell script to start stop the >> service. >> > >> > Please let me know if this is hindering anyone's work. >> > >> > 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/ >
