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