Localhost job monitoring
Hi devs, Now when I submit a job to Localhost, it doesn't do anything after launching the job. At the server level, it only shows that the job is launched. This causes the integration tests to stuck in a loop(monitoring). Any idea why this might be happening? -- Thanks, Sachith Withana
Re: Localhost job monitoring
I have noticed the same issue on Friday. I will have a look soon. Regards Lahiru On Mon, Apr 14, 2014 at 9:58 AM, Sachith Withana swsach...@gmail.comwrote: Hi devs, Now when I submit a job to Localhost, it doesn't do anything after launching the job. At the server level, it only shows that the job is launched. This causes the integration tests to stuck in a loop(monitoring). Any idea why this might be happening? -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University
Re: Localhost job monitoring
Hi Sachith, I started the server and ran createLaunchExperiment sample with localhost and it worked fine. I think this might be an issue in integration tests. Regards Lahiru On Mon, Apr 14, 2014 at 10:01 AM, Lahiru Gunathilake glah...@gmail.comwrote: I have noticed the same issue on Friday. I will have a look soon. Regards Lahiru On Mon, Apr 14, 2014 at 9:58 AM, Sachith Withana swsach...@gmail.comwrote: Hi devs, Now when I submit a job to Localhost, it doesn't do anything after launching the job. At the server level, it only shows that the job is launched. This causes the integration tests to stuck in a loop(monitoring). Any idea why this might be happening? -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University -- System Analyst Programmer PTI Lab Indiana University
Re: Localhost job monitoring
I noticed a similar issue and i found that airavata-server started by integration test was still running. I stopped the server and started server from distribution. Then everything worked well. I will try to recreate the issue and create a JIRA. Thanks Raminder On Apr 14, 2014, at 10:44 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi Sachith, I started the server and ran createLaunchExperiment sample with localhost and it worked fine. I think this might be an issue in integration tests. Regards Lahiru On Mon, Apr 14, 2014 at 10:01 AM, Lahiru Gunathilake glah...@gmail.com wrote: I have noticed the same issue on Friday. I will have a look soon. Regards Lahiru On Mon, Apr 14, 2014 at 9:58 AM, Sachith Withana swsach...@gmail.com wrote: Hi devs, Now when I submit a job to Localhost, it doesn't do anything after launching the job. At the server level, it only shows that the job is launched. This causes the integration tests to stuck in a loop(monitoring). Any idea why this might be happening? -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University -- System Analyst Programmer PTI Lab Indiana University
Re: Localhost job monitoring
Thanks Lahiru and Raman. On Mon, Apr 14, 2014 at 11:12 AM, Raminder Singh raminderjsi...@gmail.comwrote: I noticed a similar issue and i found that airavata-server started by integration test was still running. I stopped the server and started server from distribution. Then everything worked well. I will try to recreate the issue and create a JIRA. Thanks Raminder On Apr 14, 2014, at 10:44 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi Sachith, I started the server and ran createLaunchExperiment sample with localhost and it worked fine. I think this might be an issue in integration tests. Regards Lahiru On Mon, Apr 14, 2014 at 10:01 AM, Lahiru Gunathilake glah...@gmail.comwrote: I have noticed the same issue on Friday. I will have a look soon. Regards Lahiru On Mon, Apr 14, 2014 at 9:58 AM, Sachith Withana swsach...@gmail.comwrote: Hi devs, Now when I submit a job to Localhost, it doesn't do anything after launching the job. At the server level, it only shows that the job is launched. This causes the integration tests to stuck in a loop(monitoring). Any idea why this might be happening? -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University -- System Analyst Programmer PTI Lab Indiana University -- Thanks, Sachith Withana
Re: Localhost job monitoring
Hi Sachith, I just did a commit and ran the integration tests successfully[1]. Can you please confirm. [1]http://pastebin.com/pWiduqyz Lahiru On Mon, Apr 14, 2014 at 11:21 AM, Sachith Withana swsach...@gmail.comwrote: Thanks Lahiru and Raman. On Mon, Apr 14, 2014 at 11:12 AM, Raminder Singh raminderjsi...@gmail.com wrote: I noticed a similar issue and i found that airavata-server started by integration test was still running. I stopped the server and started server from distribution. Then everything worked well. I will try to recreate the issue and create a JIRA. Thanks Raminder On Apr 14, 2014, at 10:44 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi Sachith, I started the server and ran createLaunchExperiment sample with localhost and it worked fine. I think this might be an issue in integration tests. Regards Lahiru On Mon, Apr 14, 2014 at 10:01 AM, Lahiru Gunathilake glah...@gmail.comwrote: I have noticed the same issue on Friday. I will have a look soon. Regards Lahiru On Mon, Apr 14, 2014 at 9:58 AM, Sachith Withana swsach...@gmail.comwrote: Hi devs, Now when I submit a job to Localhost, it doesn't do anything after launching the job. At the server level, it only shows that the job is launched. This causes the integration tests to stuck in a loop(monitoring). Any idea why this might be happening? -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University -- System Analyst Programmer PTI Lab Indiana University -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University
Re: Localhost job monitoring
Works with the new fix. Integration tests are working now. On Mon, Apr 14, 2014 at 11:56 AM, Lahiru Gunathilake glah...@gmail.comwrote: Hi Sachith, I just did a commit and ran the integration tests successfully[1]. Can you please confirm. [1]http://pastebin.com/pWiduqyz Lahiru On Mon, Apr 14, 2014 at 11:21 AM, Sachith Withana swsach...@gmail.comwrote: Thanks Lahiru and Raman. On Mon, Apr 14, 2014 at 11:12 AM, Raminder Singh raminderjsi...@gmail.com wrote: I noticed a similar issue and i found that airavata-server started by integration test was still running. I stopped the server and started server from distribution. Then everything worked well. I will try to recreate the issue and create a JIRA. Thanks Raminder On Apr 14, 2014, at 10:44 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi Sachith, I started the server and ran createLaunchExperiment sample with localhost and it worked fine. I think this might be an issue in integration tests. Regards Lahiru On Mon, Apr 14, 2014 at 10:01 AM, Lahiru Gunathilake glah...@gmail.comwrote: I have noticed the same issue on Friday. I will have a look soon. Regards Lahiru On Mon, Apr 14, 2014 at 9:58 AM, Sachith Withana swsach...@gmail.comwrote: Hi devs, Now when I submit a job to Localhost, it doesn't do anything after launching the job. At the server level, it only shows that the job is launched. This causes the integration tests to stuck in a loop(monitoring). Any idea why this might be happening? -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University -- System Analyst Programmer PTI Lab Indiana University -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University -- Thanks, Sachith Withana
[jira] [Commented] (AIRAVATA-1121) Refactor to have Server and Client configurations in one place
[ https://issues.apache.org/jira/browse/AIRAVATA-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968633#comment-13968633 ] ASF subversion and git services commented on AIRAVATA-1121: --- Commit 594098814e88c06deae3324a1560cbc48776445a in airavata's branch refs/heads/master from [~samindaw] [ https://git-wip-us.apache.org/repos/asf?p=airavata.git;h=5940988 ] AIRAVATA-1121 Refactor to have Server and Client configurations in one place -- Key: AIRAVATA-1121 URL: https://issues.apache.org/jira/browse/AIRAVATA-1121 Project: Airavata Issue Type: Task Reporter: Saminda Wijeratne -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AIRAVATA-1124) Cleaning up unused modules in the trunk for 0.12 release
[ https://issues.apache.org/jira/browse/AIRAVATA-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968634#comment-13968634 ] ASF subversion and git services commented on AIRAVATA-1124: --- Commit 0e2c10f568f583d886657ad0b536ae62f7fa04ad in airavata's branch refs/heads/master from [~samindaw] [ https://git-wip-us.apache.org/repos/asf?p=airavata.git;h=0e2c10f ] AIRAVATA-1124 Cleaning up unused modules in the trunk for 0.12 release Key: AIRAVATA-1124 URL: https://issues.apache.org/jira/browse/AIRAVATA-1124 Project: Airavata Issue Type: Task Affects Versions: 0.12 Reporter: Saminda Wijeratne Assignee: Saminda Wijeratne Fix For: 0.12 This JIRA task is created in accordance with the airavata-dev list mail [1] for cleaning up maven modules out of the Apache Airavata trunk. 1. http://markmail.org/message/wtpufpxbjabtyntx#query:+page:1+mid:i2jlwhsqnnjd57g2+state:results -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Cleaning up unused modules before the 0.12 release
hi all, I commited the changed in cleaning up the source. I didn't remove the security,xbaya and ws-messenger modules since having them would not do any harm (which also means nothing to add to the attic). But I did remove the distribution and samples inside ws-messenger instead to avoid user confusion. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker |-commons |-messagebox |-client |-distribution *[REMOVE]* |-samples *[REMOVE]* |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui |---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 On Sun, Apr 13, 2014 at 7:58 AM, Lahiru Gunathilake glah...@gmail.comwrote: On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne samin...@gmail.comwrote: So any thoughts on this? If no objections shall I move ahead in removing the tagged modules? +1 On Thu, Apr 10, 2014 at 10:29 AM, Saminda Wijeratne samin...@gmail.comwrote: 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.com wrote: - 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.eduwrote: 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]*
Re: Test cases in Airavata with grid security
Hi All, I have finished adding new profile to run grid related tests and I have added set of new test cases to following modules. tools/gsissh tools/job-monitor gfac/gfac-core gfac/job-monitor orchestrator/orchestrator-core orchestrator/orchestrator-service These modules contains mainly tests to communicate with trestles,stampede and bigred2. to run the gridTests profile you should have myproxy credentials, bigred2 credentials (ssh keys or user name password). I use the following command to run the gridTests profile. mvn clean install -PgridTests -Dmyproxy.username=ogce -Dmyproxy.password=xxx -Dssh.username=lginnali -Dprivate.ssh.key=/Users/lahirugunathilake/.ssh/id_dsa -Dpublic.ssh.key=/Users/lahirugunathilake/.ssh/id_dsa.pub -Dssh.working.directory=/tmp -Dtrusted.cert.location=/Users/lahirugunathilake/Downloads/certificates -Dgsi.working.directory=/home/ogce/scratch -Dssh.host=bigred2.uits.iu.edu I need to do more improvement by not failing the build if you do not have some credentials, but for now most of the active committers have all these credentials. Please write more test cases using these properties and if you find any test failures with the already written tests please shoot an email. Regards Lahiru On Tue, Apr 1, 2014 at 2:57 PM, Suresh Marru sma...@apache.org wrote: + 1, as always I am supportive to have these specialized tests run as an optional tests and by the developers who have vested interested in making sure they are not broken. Suresh On Apr 1, 2014, at 2:52 PM, Lahiru Gunathilake glah...@gmail.com wrote: Hi Devs, I am thinking of changing the build as below in regards to Grid related Unit Tests. This mail is not about integration tests. Normal users who does not have grid credentials will invoke the default profile and it will builds all the required modules with non-grid Testcases. To identify the test cases to skip, throughout all the modules I am thinking of putting a simple filter like all the classes ends with TestWithMyProxyAuth.java,TestWithEC2Auth.java, TestWithSSHAuth.java. As an example if I want to write a test to check AdvancedInputHandler I write a test class like AdvancedInputHandlerTestWithMyProxyAuth.java. If these names are too big we can remove the Auth part, so it looks like AdvancedInputHandlerTestWithMyProxy.java. And importantly you might have requirement of changing the surefire-plugin inside your module, in that case you have to add surefire plugin in to your plugin list but please make sure that you inherit airavata-parent pom surefire-plugin configuration by putting inheritedtrue/inherited, so we are not missing parent-pom configuration in your module. If someone wants to run (mostly the developers who have grid credentials, or ec2 credentials, or ssh credentials) we are having different profiles, so the build will run like below. step 1: mvn clean install - bulid only the non-grid related tests adn build all the modules step 2: mvn clean install -PgridTests - step 1 + **/*TestWithMyProxyAuth.java step 3: mvn clean install -PsshTests - step 1 + **/*TestWithSSHAuth.java step 4: mvn clean install -Pec2Tests - step 1 + **/*TestWithEC2Auth.java step 5: mvn clean install -PallGridTest - step 2 + step 3 - This will run all the Grid related tests except EC2 With this approach any module can have tests to run with our supporting resource types, ex: orchestrator can have grid tests, ec2 tests, and bigred2 tests. WDYT ? Regards Lahiru On Thu, Mar 27, 2014 at 11:28 AM, Raminder Singh raminderjsi...@gmail.com wrote: +1 to have separate profiles for testing. Raminder On Mar 27, 2014, at 11:25 AM, Lahiru Gunathilake glah...@gmail.com wrote: Yes I was thinking of having different build profiles and in the default profile we remove the grid/ec2 related tests. So for a release we have to run the release profile which includes everything. Regards Lahiru On Thu, Mar 27, 2014 at 11:17 AM, Marlon Pierce marpi...@iu.edu wrote: How about having an all tests profile for full release testing? Marlon On 3/27/14 11:11 AM, Suresh Marru wrote: Also, same could be argued for other providers like EC2, Unicore and so on. I mean you want to have Unicore to european clusters a test case and if a XSEDE developer does not have those credentials, those tests should be in separate silos as well. Suresh On Mar 27, 2014, at 11:09 AM, Suresh Marru sma...@apache.org wrote: + 1, I like this tradeoff. Suresh On Mar 27, 2014, at 11:07 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, Currently in Airavata trunk we have disabled all the tests with grid security, main reason is normal user who comes to airavata might not have any grid security to build airavata with tests. I think we have to separate out grid related tests and run them separate from a normal build and write more test cases to test
Re: Cleaning up unused modules before the 0.12 release
Thanks Saminda, this looks like a great list and a much needed cleanup job. Suresh On Mon, Apr 14, 2014 at 2:40 PM, Saminda Wijeratne samin...@gmail.comwrote: hi all, I commited the changed in cleaning up the source. I didn't remove the security,xbaya and ws-messenger modules since having them would not do any harm (which also means nothing to add to the attic). But I did remove the distribution and samples inside ws-messenger instead to avoid user confusion. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker |-commons |-messagebox |-client |-distribution *[REMOVE]* |-samples *[REMOVE]* |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui |---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 On Sun, Apr 13, 2014 at 7:58 AM, Lahiru Gunathilake glah...@gmail.comwrote: On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne samin...@gmail.comwrote: So any thoughts on this? If no objections shall I move ahead in removing the tagged modules? +1 On Thu, Apr 10, 2014 at 10:29 AM, Saminda Wijeratne samin...@gmail.comwrote: 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.com wrote: - 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.eduwrote: 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
[jira] [Created] (AIRAVATA-1139) Cannot get all user projects
David Reagan created AIRAVATA-1139: -- Summary: Cannot get all user projects Key: AIRAVATA-1139 URL: https://issues.apache.org/jira/browse/AIRAVATA-1139 Project: Airavata Issue Type: Bug Components: Airavata Client Environment: PHP Reporter: David Reagan Fix For: 0.12 getAllUserProjects(admin) throws a TTransportException Fatal error: Uncaught exception 'Thrift\Exception\TTransportException' with message 'TSocket read 0 bytes' in C:\wamp\www\Airavata-PHP-Client-Samples\lib\Thrift\Transport\TSocket.php on line 269 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AIRAVATA-1137) Security module obsolete
[ https://issues.apache.org/jira/browse/AIRAVATA-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saminda Wijeratne resolved AIRAVATA-1137. - Resolution: Fixed Removed this from the build. But it will remain in the source since it'll be updated and used in the next release. Security module obsolete Key: AIRAVATA-1137 URL: https://issues.apache.org/jira/browse/AIRAVATA-1137 Project: Airavata Issue Type: Task Reporter: Marlon Pierce Priority: Minor Only the obsolete modules/rest has dependencies on modules/security, and the build works fine with it commented out. Nice code though, should be put in an attic someplace so we can easily find it and repurpose it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AIRAVATA-1121) Refactor to have Server and Client configurations in one place
[ https://issues.apache.org/jira/browse/AIRAVATA-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saminda Wijeratne resolved AIRAVATA-1121. - Resolution: Fixed fixed Refactor to have Server and Client configurations in one place -- Key: AIRAVATA-1121 URL: https://issues.apache.org/jira/browse/AIRAVATA-1121 Project: Airavata Issue Type: Task Reporter: Saminda Wijeratne -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AIRAVATA-1124) Cleaning up unused modules in the trunk for 0.12 release
[ https://issues.apache.org/jira/browse/AIRAVATA-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saminda Wijeratne resolved AIRAVATA-1124. - Resolution: Fixed security, xbaya-gui, ws-messenger/messagebox, ws-messenger/messagebroker modules will not be removed. the logic of removing the modules is to remove any modules which we will not need now or in the future and remove any module which will cause confusion to a user who will download the source of this release (eg: unused distrobutions, broken samples). Cleaning up unused modules in the trunk for 0.12 release Key: AIRAVATA-1124 URL: https://issues.apache.org/jira/browse/AIRAVATA-1124 Project: Airavata Issue Type: Task Affects Versions: 0.12 Reporter: Saminda Wijeratne Assignee: Saminda Wijeratne Fix For: 0.12 This JIRA task is created in accordance with the airavata-dev list mail [1] for cleaning up maven modules out of the Apache Airavata trunk. 1. http://markmail.org/message/wtpufpxbjabtyntx#query:+page:1+mid:i2jlwhsqnnjd57g2+state:results -- This message was sent by Atlassian JIRA (v6.2#6252)
