airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lahiru Gunathilake <glah...@gmail.com>
Subject Re: Cleaning up unused modules before the 0.12 release
Date Sun, 13 Apr 2014 14:58:02 GMT
On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne <samindaw@gmail.com>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 <samindaw@gmail.com>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 <swsachith@gmail.com>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 <samindaw@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 <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
>>>>> 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 <
>>>>> 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
>>>>> commented
>>>>> >> or not).
>>>>> >>
>>>>> >> 1. https://issues.apache.org/jira/browse/AIRAVATA-1124
>>>>> >>
>>>>> >>
>>>>> >> On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne <
>>>>> samindaw@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 <smarru@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 <
>>>>> 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
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

Mime
View raw message