You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Lahiru Gunathilake <gl...@gmail.com> on 2014/03/31 16:10:44 UTC
Cleaning up unused modules before the 0.12 release
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
Re: Cleaning up unused modules before the 0.12 release
Posted by Marlon Pierce <ma...@iu.edu>.
I also don't think we should ship these. Can we delete the REST
module? It will always be in the 0.11 tag. One option for the
remaining stuff (which we will return to, like the Workflow-Interpreter)
is to leave them in the trunk/master and omit them from the 0.12 tag
release.
Marlon
On 3/31/14 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
>
>
Re: Cleaning up unused modules before the 0.12 release
Posted by Suresh Marru <sm...@apache.org>.
Thanks Saminda, this looks like a great list and a much needed cleanup job.
Suresh
On Mon, Apr 14, 2014 at 2:40 PM, Saminda Wijeratne <sa...@gmail.com>wrote:
> hi all,
>
> I commited the changed in cleaning up the source. I didn't remove the
> security,xbaya and ws-messenger modules since having them would not do any
> harm (which also means nothing to add to the attic). But I did remove the
> distribution and samples inside ws-messenger instead to avoid user
> confusion.
>
> |-modules
> |---commons
> |-----utils
> |-----json *[REMOVE]*
> |-----workflow-execution-context
> |-----gfac-schema
> |-----workflow-tracking
> |---security
> |---server
> |---rest *[REMOVE]*
>
> |-----client
> |-----webapp
> |-----mappings
> |-----service
> |---configuration
> |-----server
> |-----client
> |---orchestrator
> |-----orchestrator-core
> |-----airavata-orchestrator-service
> |-----orchestrator-client-sdks
> |---ws-messenger
> |-----messagebroker
> |-----commons
> |-----messagebox
> |-----client
> |-----distribution *[REMOVE]*
> |-----samples *[REMOVE]*
>
> |-----message-monitor
> |---test-suite
> |---workflow-model
> |-----workflow-model-component-node *[REMOVE]*
> |-----workflow-model-core
> |-----workflow-model-component *[REMOVE]*
> |---xbaya-gui
> |---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
>
>
>
> On Sun, Apr 13, 2014 at 7:58 AM, Lahiru Gunathilake <gl...@gmail.com>wrote:
>
>>
>>
>>
>> On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne <sa...@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 <sa...@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 <sw...@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 <ma...@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
>>
>
>
Re: Cleaning up unused modules before the 0.12 release
Posted by Saminda Wijeratne <sa...@gmail.com>.
hi all,
I commited the changed in cleaning up the source. I didn't remove the
security,xbaya and ws-messenger modules since having them would not do any
harm (which also means nothing to add to the attic). But I did remove the
distribution and samples inside ws-messenger instead to avoid user
confusion.
|-modules
|---commons
|-----utils
|-----json *[REMOVE]*
|-----workflow-execution-context
|-----gfac-schema
|-----workflow-tracking
|---security
|---server
|---rest *[REMOVE]*
|-----client
|-----webapp
|-----mappings
|-----service
|---configuration
|-----server
|-----client
|---orchestrator
|-----orchestrator-core
|-----airavata-orchestrator-service
|-----orchestrator-client-sdks
|---ws-messenger
|-----messagebroker
|-----commons
|-----messagebox
|-----client
|-----distribution *[REMOVE]*
|-----samples *[REMOVE]*
|-----message-monitor
|---test-suite
|---workflow-model
|-----workflow-model-component-node *[REMOVE]*
|-----workflow-model-core
|-----workflow-model-component *[REMOVE]*
|---xbaya-gui
|---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
On Sun, Apr 13, 2014 at 7:58 AM, Lahiru Gunathilake <gl...@gmail.com>wrote:
>
>
>
> On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne <sa...@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 <sa...@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 <sw...@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 <ma...@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 <sm...@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
>
Re: Cleaning up unused modules before the 0.12 release
Posted by Lahiru Gunathilake <gl...@gmail.com>.
On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne <sa...@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 <sa...@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 <sw...@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 <sa...@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 <ma...@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 <sm...@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
Re: Cleaning up unused modules before the 0.12 release
Posted by Saminda Wijeratne <sa...@gmail.com>.
So any thoughts on this? If no objections shall I move ahead in removing
the tagged modules?
On Thu, Apr 10, 2014 at 10:29 AM, Saminda Wijeratne <sa...@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 <sw...@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 <sa...@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 <ma...@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 <sm...@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
>>
>>
>
Re: Cleaning up unused modules before the 0.12 release
Posted by Saminda Wijeratne <sa...@gmail.com>.
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 <sw...@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 <sa...@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 <ma...@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 <sm...@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
>
>
Re: Cleaning up unused modules before the 0.12 release
Posted by Sachith Withana <sw...@gmail.com>.
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 <sa...@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 <ma...@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 <sm...@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 <gl...@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
Re: Cleaning up unused modules before the 0.12 release
Posted by Saminda Wijeratne <sa...@gmail.com>.
- 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 <ma...@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 <sm...@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 <gl...@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
> >>>>
>
>
Re: Cleaning up unused modules before the 0.12 release
Posted by Marlon Pierce <ma...@iu.edu>.
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 <sa...@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 <sa...@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 <sm...@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 <gl...@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
>>>>
Re: Cleaning up unused modules before the 0.12 release
Posted by Saminda Wijeratne <sa...@gmail.com>.
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 <sa...@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 <sa...@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 <sm...@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 <gl...@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
>>>
>>>
>>
>
Re: Cleaning up unused modules before the 0.12 release
Posted by Saminda Wijeratne <sa...@gmail.com>.
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 <sa...@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 <sm...@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 <gl...@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
>>
>>
>
Re: Cleaning up unused modules before the 0.12 release
Posted by Saminda Wijeratne <sa...@gmail.com>.
+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 <sm...@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 <gl...@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
>
>
Re: Cleaning up unused modules before the 0.12 release
Posted by Suresh Marru <sm...@apache.org>.
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 <gl...@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