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.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 >> >>>>> 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
