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 2014/02/10 16:21:41 UTC
Airavata API update and lock for 2 days
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
Re: Airavata API update and lock for 2 days
Posted by Suresh Marru <sm...@apache.org>.
On Feb 10, 2014, at 4:04 PM, Chathuri Wimalasena <ka...@gmail.com> wrote:
> 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 ?
We can iterate how to best organize all these through next couple of releases, but for now, i felt its better to have only one copy of the generated boilerplate code in airavata-api-sdk and the server can have both the server administration and the handler.
Suresh
>
> Thanks..
> Chathuri
>
>
> On Mon, Feb 10, 2014 at 3:18 PM, Shameera Rathnayaka <sh...@gmail.com> 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 <sm...@apache.org> 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 <sh...@gmail.com> 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 <sm...@apache.org> 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/
>
Re: Airavata API update and lock for 2 days
Posted by Chathuri Wimalasena <ka...@gmail.com>.
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 <shameerainfo@gmail.com
> 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 <sm...@apache.org> 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 <sh...@gmail.com>
>> 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 <sm...@apache.org>
>> 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/
>
Re: Airavata API update and lock for 2 days
Posted by Shameera Rathnayaka <sh...@gmail.com>.
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 <sm...@apache.org> 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 <sh...@gmail.com>
> 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 <sm...@apache.org> 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/
Re: Airavata API update and lock for 2 days
Posted by Suresh Marru <sm...@apache.org>.
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 <sh...@gmail.com> 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 <sm...@apache.org> 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/
Re: Airavata API update and lock for 2 days
Posted by Shameera Rathnayaka <sh...@gmail.com>.
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 <sm...@apache.org> 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/