On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne <[email protected]>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 <[email protected]>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 <[email protected]>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 >>> <[email protected]>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 <[email protected]> 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 < >>>>> [email protected]>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 < >>>>> [email protected]>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 <[email protected]> >>>>> 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 < >>>>> [email protected]> >>>>> >>>> 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 >>>>> >>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Thanks, >>> Sachith Withana >>> >>> >> > -- System Analyst Programmer PTI Lab Indiana University
