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 wrote: > 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 wrote: > >> >> >> >> On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne >> wrote: >> >>> 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 >>> wrote: >>> 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 wrote: > 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 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
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 wrote: > > > > On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne wrote: > >> 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 >> wrote: >> >>> 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 wrote: >>> 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 >>> > 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 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 >> >|---
Re: Cleaning up unused modules before the 0.12 release
On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne wrote: > 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 wrote: > >> 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 wrote: >> >>> 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 >>> 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 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 < >>
Re: Cleaning up unused modules before the 0.12 release
So any thoughts on this? If no objections shall I move ahead in removing the tagged modules? On Thu, Apr 10, 2014 at 10:29 AM, Saminda Wijeratne wrote: > 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 wrote: > >> 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 >> 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 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 >>> >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
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 wrote: > 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 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 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 >> >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
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 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 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 > >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 > >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. Thu
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 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 >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 >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 > 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 > wrote: > > > Hi All, > > > > In 0.12 release we are
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 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 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 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 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
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 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 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 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 >>> 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
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 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 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 >> 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
+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 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 > 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
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 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
I also don't think we should ship these. Can we delete the REST module? It will always be in the 0.11 tag. One option for the remaining stuff (which we will return to, like the Workflow-Interpreter) is to leave them in the trunk/master and omit them from the 0.12 tag release. Marlon On 3/31/14 10:10 AM, Lahiru Gunathilake 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 > >
