Return-Path: X-Original-To: apmail-airavata-dev-archive@www.apache.org Delivered-To: apmail-airavata-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 37E9E114E8 for ; Thu, 10 Apr 2014 16:54:21 +0000 (UTC) Received: (qmail 79028 invoked by uid 500); 10 Apr 2014 16:54:15 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 78903 invoked by uid 500); 10 Apr 2014 16:54:12 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 78887 invoked by uid 99); 10 Apr 2014 16:54:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Apr 2014 16:54:10 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of swsachith@gmail.com designates 209.85.212.180 as permitted sender) Received: from [209.85.212.180] (HELO mail-wi0-f180.google.com) (209.85.212.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Apr 2014 16:54:06 +0000 Received: by mail-wi0-f180.google.com with SMTP id q5so5345583wiv.7 for ; Thu, 10 Apr 2014 09:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=n0tDYvmZMOgxnAKhP9jBJRebStMGpiG0BiLBavrVRLU=; b=u63POZ1tURVK4u8aasel4ScmBz8uZQjXvWajqndpB0PXPe5pBD8wj5LbrlR4lOzodF fE3c2BD+kokqKE4MiMVmMvFDzlXW2gnG3EibyxPj2ePU6amv7wQi1n2tXfxz2mx7Xzlo 8NJuLzNPkD8tMBHXb5sE5MJ+HQOtDInRHJXN9ZeIWujm+mnBa2PvDlN/hjkt+oluUnp0 aHEXoAb4xCQwYX+q3yN2EiSmMtBVIUuO2Qexl/L1BUQ5HZHG+NKdHER3zT719i8u5nu0 PUMRVnt6l1w/hxF55aazCriOTbp5r20BooLqBNmFYzcau5co1XmF7KZ4JLC5yHXrVitN Y+Sw== MIME-Version: 1.0 X-Received: by 10.194.78.4 with SMTP id x4mr3218341wjw.58.1397148824962; Thu, 10 Apr 2014 09:53:44 -0700 (PDT) Received: by 10.217.94.201 with HTTP; Thu, 10 Apr 2014 09:53:44 -0700 (PDT) In-Reply-To: References: <7C09263D-3A0A-4228-90A8-4747E598E0D7@apache.org> <53467A52.2080006@iu.edu> Date: Thu, 10 Apr 2014 10:53:44 -0600 Message-ID: Subject: Re: Cleaning up unused modules before the 0.12 release From: Sachith Withana To: dev@airavata.apache.org Content-Type: multipart/alternative; boundary=047d7bfcf914690b7d04f6b30f31 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bfcf914690b7d04f6b30f31 Content-Type: text/plain; charset=ISO-8859-1 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. 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 >> >>>> >> >> > -- Thanks, Sachith Withana --047d7bfcf914690b7d04f6b30f31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Since Modules like=A0ws-messenger,xbaya and the=A0= workflow-interpreter will be re-integrated to Airavata,=A0
is it possible for us to just remove these= modules in a 0.12 release branch and ship the source without these modules= ?

<= font face=3D"arial, sans-serif">BUT keep those in the trunk, since it will = be re-integrated?=A0

So the release branch wouldn't have unused code but the trunk will.= =A0

Also +1 to deleting the Rest module.


On Thu, Apr 10, 2014 a= t 10:43 AM, Saminda Wijeratne <samindaw@gmail.com> wrote:
- If the code had= n't changed since last release theoretically speaking, we should be abl= e to build each module which we moved to attic individually (with the versi= on 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, M= arlon Pierce <marpierc@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 tru= nk.
> 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.
>
> =A0 =A0|-modules
> =A0 =A0|---commons
> =A0 =A0|-----utils
> =A0 =A0|-----json *[REMOVE]*
> =A0 =A0|-----workflow-execution-context
> =A0 =A0|-----gfac-schema
> =A0 =A0|-----workflow-tracking
> =A0 =A0|---security *[REMOVE][ATTIC]*
> =A0 =A0|---server
> =A0 =A0|---rest *[REMOVE]*
> =A0 =A0|-----client
> =A0 =A0|-----webapp
> =A0 =A0|-----mappings
> =A0 =A0|-----service
> =A0 =A0|---configuration
> =A0 =A0|-----server
> =A0 =A0|-----client
> =A0 =A0|---orchestrator
> =A0 =A0|-----orchestrator-core
> =A0 =A0|-----airavata-orchestrator-service
> =A0 =A0|-----orchestrator-client-sdks
> =A0 =A0|---ws-messenger
> =A0 =A0|-----messagebroker *[REMOVE][ATTIC]*
> =A0 =A0|-----commons
> =A0 =A0|-----messagebox *[REMOVE]**[ATTIC]*
> =A0 =A0|-----client
> =A0 =A0|-----distribution
> =A0 =A0|-----message-monitor
> =A0 =A0|---test-suite
> =A0 =A0|---workflow-model
> =A0 =A0|-----workflow-model-component-node *[REMOVE]*
> =A0 =A0|-----workflow-model-core
> =A0 =A0|-----workflow-model-component *[REMOVE]*
> =A0 =A0|---xbaya-gui *[REMOVE][ATTIC]*
> =A0 =A0|---registry
> =A0 =A0|-----airavata-registry-test *[REMOVE]*
> =A0 =A0|-----airavata-jpa-registry
> =A0 =A0|-----registry-api
> =A0 =A0|-----registry-cpi
> =A0 =A0|-----airavata-registry-service *[REMOVE]*
> =A0 =A0|---credential-store
> =A0 =A0|---integration-tests
> =A0 =A0|---distribution
> =A0 =A0|-----airavata-server
> =A0 =A0|-----xbaya-gui *[REMOVE]*
> =A0 =A0|-----release
> =A0 =A0|-----airavata-client
> =A0 =A0|---gfac
> =A0 =A0|-----gfac-core
> =A0 =A0|-----gfac-ec2
> =A0 =A0|-----gfac-monitor
> =A0 =A0|---airavata-client
> =A0 =A0|---workflow-interpreter *[REMOVE]*
> =A0 =A0|-airavata-api
> =A0 =A0|---airavata-model-utils
> =A0 =A0|---airavata-api-server
> =A0 =A0|---airavata-api-stubs
> =A0 =A0|---airavata-data-models
> =A0 =A0|---airavata-client-sdks
> =A0 =A0|-----java-client-samples
> =A0 =A0|-tools
> =A0 =A0|---job-monitor
> =A0 =A0|---registry-tool
> =A0 =A0|---gsissh
> =A0 =A0|---phoebus-integration
> =A0 =A0|-samples *[REMOVE]*
> =A0 =A0|---simple-math-service
> =A0 =A0|---sample-gateway
> =A0 =A0|---levenshtein-distance-service
> =A0 =A0|---provenance-registry-handler
> =A0 =A0|---gateway-developer-guide
> =A0 =A0|---echo-service
> =A0 =A0|---distribution
> =A0 =A0|---airavata-client
> =A0 =A0|-----create-application
> =A0 =A0|-----workflow-run
> =A0 =A0|---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 <samindaw@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 c= ommented
>> or not).
>>
>> 1. https://issues.apache.org/jira/browse/AIRAVATA-1124<= br> >>
>>
>> On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne <samindaw@gmail.com>wrot= e:
>>
>>> +1 for deleting the Rest module.
>>>
>>> Generally I'm inclined towards keeping the other modules s= ince 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 th= at already
>>> when we moved to git recently. Thus this could be one rare sit= uation
>>> deleting at this point is justified?
>>>
>>>
>>> On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru <smarru@apache.org> wrote= :
>>>
>>>> Lahiru,
>>>>
>>>> I see two parts of this cleanup. The modules we will integ= rate 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 <glahiru@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 w= ith 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 re= lease. Either we
>>>> have to fix the trunk by moving these code to sandbox or t= o another branch
>>>> or we have to branch 0.12 without these modules and make a= iravata compile
>>>> and work and then release 0.12.
>>>>> WDYT ?
>>>>>
>>>>> Regards
>>>>> Lahiru
>>>>>
>>>>>
>>>>> --
>>>>> System Analyst Programmer
>>>>> PTI Lab
>>>>> Indiana University
>>>>





--
=
Thanks,
Sachith Withana

--047d7bfcf914690b7d04f6b30f31--