Re: Cleaning up unused modules before the 0.12 release
Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.comwrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules/ws-messenger/message-monitor modules/ws-messenger/messagebox modules/ws-messenger/messagebroker modules/ws-messenger/samples modules/rest/client modules/rest/mapping modules/rest/service modules/rest/webapp I think we should not ship these unused code in the release. Either we have to fix the trunk by moving these code to sandbox or to another branch or we have to branch 0.12 without these modules and make airavata compile and work and then release 0.12. WDYT ? Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University
Re: Gram or GSI-SSH working test case
Hi Marlon, I want to run a GFac provider test case in which all the associated entities (input/output handlers) of a provider are invoked. The good news is I am able to run a simple provider test case (partially), wherein the provider's input handlers are invoked, but not the output handlers. Thanks to Raminder and Lahiru. The test case Lahiru has mentioned is not entering the GSI-SSH's output handlers because it is required to have job submitted through EmbeddedGfacJobSubmitter instead of GfacImpl. To test the minimal provider functionality it would be helpful to have a unit test that is running through all the mandatory life cycle phases of a provider (without requiring an external server instance). Thanks for the replies. Cheers, Shahbaz On Wed, Apr 9, 2014 at 7:11 PM, Lahiru Gunathilake glah...@gmail.comwrote: Hi Shabhaz, If you just want a unit test you can run GSISSHProviderTestWithMyProxyAuth.java in gfac-core/src/test/java. Before run it you need to configure it with right credentials. I am still working on getting gfac tests with maven. Regards Lahiru On Mon, Apr 7, 2014 at 9:38 AM, Lahiru Gunathilake glah...@gmail.comwrote: You can use git/airavata/airavata-api/airavata-client-sdks/java-client-samples/src/main/java/org/apache/airavata/client/samples/CreateLaunchExperiment.java class to test gsissh support, in trunk we do not support gram. Unless you implement a monitoring mechanism and come to a conclusion about the state your outhandlers will not get executed. 2014-04-07 9:12 GMT-04:00 Shahbaz Memon m.me...@fz-juelich.de: Hi Devs, Please can someone point me to a working GSI-SSH or Gram job execution test case? Thanks, Shahbaz Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt -- System Analyst Programmer PTI Lab Indiana University -- System Analyst Programmer PTI Lab Indiana University
Re: Cleaning up unused modules before the 0.12 release
The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.comwrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules/ws-messenger/message-monitor modules/ws-messenger/messagebox modules/ws-messenger/messagebroker modules/ws-messenger/samples modules/rest/client modules/rest/mapping modules/rest/service modules/rest/webapp I think we should not ship these unused code in the release. Either we have to fix the trunk by moving these code to sandbox or to another branch or we have to branch 0.12 without these modules and make airavata compile and work and then release 0.12. WDYT ? Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University
Re: Cleaning up unused modules before the 0.12 release
- If the code hadn't changed since last release theoretically speaking, we should be able to build each module which we moved to attic individually (with the version set to 0.11) because the maven repo should have its dependencies. - Other option what Marlon suggested as I understood is to attic all other dependent modules (atleast a copy of it to the attic) along with the parent POM and all. This might cause some conflicts related to modules that are in the actual trunk if someone decides to work in both trunk and attic. wdyt is the best way to go? (or any other approaches?) On Thu, Apr 10, 2014 at 4:02 AM, Marlon Pierce marpi...@iu.edu wrote: The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.com wrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.com wrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution
Re: Cleaning up unused modules before the 0.12 release
Since Modules like ws-messenger,xbaya and the workflow-interpreter will be re-integrated to Airavata, is it possible for us to just remove these modules in a 0.12 release branch and ship the source without these modules? BUT keep those in the trunk, since it will be re-integrated? So the release branch wouldn't have unused code but the trunk will. Also +1 to deleting the Rest module. On Thu, Apr 10, 2014 at 10:43 AM, Saminda Wijeratne samin...@gmail.comwrote: - If the code hadn't changed since last release theoretically speaking, we should be able to build each module which we moved to attic individually (with the version set to 0.11) because the maven repo should have its dependencies. - Other option what Marlon suggested as I understood is to attic all other dependent modules (atleast a copy of it to the attic) along with the parent POM and all. This might cause some conflicts related to modules that are in the actual trunk if someone decides to work in both trunk and attic. wdyt is the best way to go? (or any other approaches?) On Thu, Apr 10, 2014 at 4:02 AM, Marlon Pierce marpi...@iu.edu wrote: The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.com wrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.com wrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the
Re: Cleaning up unused modules before the 0.12 release
That I suppose would be the ideal case, but I do not know whether this is possible to do in the release process. Suresh, any thoughts? On Thu, Apr 10, 2014 at 9:53 AM, Sachith Withana swsach...@gmail.comwrote: Since Modules like ws-messenger,xbaya and the workflow-interpreter will be re-integrated to Airavata, is it possible for us to just remove these modules in a 0.12 release branch and ship the source without these modules? BUT keep those in the trunk, since it will be re-integrated? So the release branch wouldn't have unused code but the trunk will. Also +1 to deleting the Rest module. On Thu, Apr 10, 2014 at 10:43 AM, Saminda Wijeratne samin...@gmail.comwrote: - If the code hadn't changed since last release theoretically speaking, we should be able to build each module which we moved to attic individually (with the version set to 0.11) because the maven repo should have its dependencies. - Other option what Marlon suggested as I understood is to attic all other dependent modules (atleast a copy of it to the attic) along with the parent POM and all. This might cause some conflicts related to modules that are in the actual trunk if someone decides to work in both trunk and attic. wdyt is the best way to go? (or any other approaches?) On Thu, Apr 10, 2014 at 4:02 AM, Marlon Pierce marpi...@iu.edu wrote: The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.com wrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh
Missing features in new architecture
Hi devs, Due to the architecture change I thought of discussing what are the missing features in current trunk compared to 0.11 release. Of course we need to do lot more features that 0.11 release but I think before that we can finalize what we still need do to fix the gap between 0.11 and next release. If we are not planning to do features in 0.11 release we can cut them down and focus on the rest. 1. Workflow support and non of the xbaya features are working in trunk. 2. There is no workflow interpreter service and if we are planning to get rid of axis2 we have to make workflow interpreter as a thrift service. 3. There is not notification mechanism between the client and the server, to get a status we always have to pull from the registry. 4. There is no credential store support in trunk. 5. We need to update most of the unit tests and make sure atleast we have the unit tests which we had for 0.11 release. I am sure I have missed some here, so if you have any missing features in trunk due to re-architecting happen, please reply so that we can create a jira with sub-tasks and work on them. Thanks Lahiru -- System Analyst Programmer PTI Lab Indiana University
