Re: Unused modules
Thanks Dimuthu > On Dec 28, 2018, at 6:52 AM, DImuthu Upeksha > wrote: > > Hi Marcus, > > I brought it back [1] > > Dimuthu > > [1] > https://github.com/apache/airavata/commit/78a22163a39a9985d34fa635754ebf9064ee8305 > > <https://github.com/apache/airavata/commit/78a22163a39a9985d34fa635754ebf9064ee8305> > On Mon, Dec 17, 2018 at 8:51 AM Christie, Marcus Aaron <mailto:machr...@iu.edu>> wrote: > Hi Dimuthu, > > Yes, it's loaded at runtime. See the db_event_manager property in > airavata-server.properties. See also [1]. > > Thanks, > > Marcus > > [1] > https://github.com/apache/airavata/blob/33a601fe84d297b11171a1157a2561a451ad9d84/modules/server/src/main/java/org/apache/airavata/server/ServerMain.java#L126-L126 > > <https://github.com/apache/airavata/blob/33a601fe84d297b11171a1157a2561a451ad9d84/modules/server/src/main/java/org/apache/airavata/server/ServerMain.java#L126-L126> > > >> On Dec 16, 2018, at 3:57 AM, DImuthu Upeksha > <mailto:dimuthu.upeks...@gmail.com>> wrote: >> >> Hi Marcus, >> >> Thanks for raising this issue. Is that a runtime dependency? For me, >> everything compiled without db-event-manager [1]. Can you point me to the >> place where we are using that? >> >> [1] https://travis-ci.org/apache/airavata/builds/465830628 >> <https://travis-ci.org/apache/airavata/builds/465830628> >> >> Thanks, >> Dimuthu >> >> On Wed, Dec 12, 2018 at 6:22 AM Christie, Marcus Aaron > <mailto:machr...@iu.edu>> wrote: >> Hi Dimuthu, >> >> Thanks for cleaning things up! However, I'm pretty sure we're still using >> db-event-manager to manage our event-based synchronization between Airavata >> services. >> >> The rest looks good to be removed though. >> >> Thanks, >> >> Marcus >> >>> On Dec 10, 2018, at 1:08 AM, DImuthu Upeksha >> <mailto:dimuthu.upeks...@gmail.com>> wrote: >>> >>> Hi Folks, >>> >>> I removed following modules on staging branch [1] and created a separate >>> branch named archive to keep old changes. >>> >>> allocation-manager >>> cloud >>> db-event-manager >>> gfac >>> integration-tests >>> monitoring >>> test-suite >>> workflow >>> workflow-model >>> xbaya >>> xbaya-gui >>> >>> Following modules were kept as there are some dependencies to other modules >>> >>> compute-account-provisioning >>> configuration >>> security >>> >>> Updated repository was tested in the Testing environment and everything >>> seems to be running smoothly. I will redeploy Staging setup in few days and >>> merge changes to develop branch as well. >>> >>> Thanks >>> Dimuthu >>> >>> [1] https://github.com/apache/airavata/tree/staging/modules >>> <https://github.com/apache/airavata/tree/staging/modules> >>> >>> On Fri, Nov 30, 2018 at 8:32 PM Suresh Marru >> <mailto:sma...@apache.org>> wrote: >>> Hi Sudhakar, >>> >>> The allocation manager from last year contributions is here - >>> https://github.com/apache/airavata-sandbox/tree/master/allocation-manager >>> <https://github.com/apache/airavata-sandbox/tree/master/allocation-manager> >>> the one Dimuthu is suggesting to clean up is a stale one. >>> >>> I think we should turn the allocation manager into a larger goal of >>> enforcing quotas mainly for user storage and probably take on as soon as >>> possible. >>> >>> Cheers, >>> Suresh >>> >>>> On Nov 30, 2018, at 8:37 AM, Pamidighantam, Sudhakar V >>>> mailto:spami...@illinois.edu>> wrote: >>>> >>>> What is the estimated timeline for enforceable allocation management to be >>>> available in Airavata, 2019, 2020? >>>> >>>> Thanks, >>>> Sudhakar. >>>> >>>> From: DImuthu Upeksha >>> <mailto:dimuthu.upeks...@gmail.com>> >>>> Reply-To: "dev@airavata.apache.org <mailto:dev@airavata.apache.org>" >>>> mailto:dev@airavata.apache.org>> >>>> Date: Friday, November 30, 2018 at 8:30 AM >>>> To: "dev@airavata.apache.org <mailto:dev@airavata.apache.org>" >>>> mailto:dev@airavata.apache.org>> >>>> Subject: Re: Unused modules >>>
Re: Unused modules
Hi Marcus, I brought it back [1] Dimuthu [1] https://github.com/apache/airavata/commit/78a22163a39a9985d34fa635754ebf9064ee8305 On Mon, Dec 17, 2018 at 8:51 AM Christie, Marcus Aaron wrote: > Hi Dimuthu, > > Yes, it's loaded at runtime. See the db_event_manager property in > airavata-server.properties. See also [1]. > > Thanks, > > Marcus > > [1] > https://github.com/apache/airavata/blob/33a601fe84d297b11171a1157a2561a451ad9d84/modules/server/src/main/java/org/apache/airavata/server/ServerMain.java#L126-L126 > > > On Dec 16, 2018, at 3:57 AM, DImuthu Upeksha > wrote: > > Hi Marcus, > > Thanks for raising this issue. Is that a runtime dependency? For me, > everything compiled without db-event-manager [1]. Can you point me to the > place where we are using that? > > [1] https://travis-ci.org/apache/airavata/builds/465830628 > > Thanks, > Dimuthu > > On Wed, Dec 12, 2018 at 6:22 AM Christie, Marcus Aaron > wrote: > >> Hi Dimuthu, >> >> Thanks for cleaning things up! However, I'm pretty sure we're still >> using db-event-manager to manage our event-based synchronization between >> Airavata services. >> >> The rest looks good to be removed though. >> >> Thanks, >> >> Marcus >> >> On Dec 10, 2018, at 1:08 AM, DImuthu Upeksha >> wrote: >> >> Hi Folks, >> >> I removed following modules on staging branch [1] and created a separate >> branch named archive to keep old changes. >> >> allocation-manager >> cloud >> db-event-manager >> gfac >> integration-tests >> monitoring >> test-suite >> workflow >> workflow-model >> xbaya >> xbaya-gui >> >> Following modules were kept as there are some dependencies to other >> modules >> >> compute-account-provisioning >> configuration >> security >> >> Updated repository was tested in the Testing environment and everything >> seems to be running smoothly. I will redeploy Staging setup in few days and >> merge changes to develop branch as well. >> >> Thanks >> Dimuthu >> >> [1] https://github.com/apache/airavata/tree/staging/modules >> >> On Fri, Nov 30, 2018 at 8:32 PM Suresh Marru wrote: >> >>> Hi Sudhakar, >>> >>> The allocation manager from last year contributions is here - >>> https://github.com/apache/airavata-sandbox/tree/master/allocation-manager >>> the >>> one Dimuthu is suggesting to clean up is a stale one. >>> >>> I think we should turn the allocation manager into a larger goal of >>> enforcing quotas mainly for user storage and probably take on as soon as >>> possible. >>> >>> Cheers, >>> Suresh >>> >>> On Nov 30, 2018, at 8:37 AM, Pamidighantam, Sudhakar V < >>> spami...@illinois.edu> wrote: >>> >>> What is the estimated timeline for enforceable allocation management to >>> be available in Airavata, 2019, 2020? >>> >>> Thanks, >>> Sudhakar. >>> >>> *From: *DImuthu Upeksha >>> *Reply-To: *"dev@airavata.apache.org" >>> *Date: *Friday, November 30, 2018 at 8:30 AM >>> *To: *"dev@airavata.apache.org" >>> *Subject: *Re: Unused modules >>> >>> Hi Suresh, >>> >>> +1 for removing gfac modules as well >>> >>> Dimuthu >>> >>> On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata >>> wrote: >>> >>> +1 to remove all of them. While you are at it, should we also remove >>> gfac modules from develop and staging branches? >>> >>> Suresh >>> >>> >>> >>> On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha >>> wrote: >>> >>> Hi Folks, >>> >>> I can see that some modules [1] are no longer being used or actively >>> developed. >>> >>> allocation-manager >>> cloud >>> compute-account-provisioning >>> configuration >>> db-event-manager >>> integration-tests >>> monitoring >>> security >>> workflow >>> workflow-model >>> xbaya >>> xbaya-gui >>> >>> I'm suggesting to remove these unused modules as they affect the build >>> time and the clarity of the code. Any objections / suggestions? >>> >>> [1] https://github.com/apache/airavata/tree/staging/modules >>> >>> Thanks >>> Dimuthu >>> >>> >>> >> >
Re: Unused modules
Hi Dimuthu, Yes, it's loaded at runtime. See the db_event_manager property in airavata-server.properties. See also [1]. Thanks, Marcus [1] https://github.com/apache/airavata/blob/33a601fe84d297b11171a1157a2561a451ad9d84/modules/server/src/main/java/org/apache/airavata/server/ServerMain.java#L126-L126 <https://github.com/apache/airavata/blob/33a601fe84d297b11171a1157a2561a451ad9d84/modules/server/src/main/java/org/apache/airavata/server/ServerMain.java#L126-L126> > On Dec 16, 2018, at 3:57 AM, DImuthu Upeksha > wrote: > > Hi Marcus, > > Thanks for raising this issue. Is that a runtime dependency? For me, > everything compiled without db-event-manager [1]. Can you point me to the > place where we are using that? > > [1] https://travis-ci.org/apache/airavata/builds/465830628 > <https://travis-ci.org/apache/airavata/builds/465830628> > > Thanks, > Dimuthu > > On Wed, Dec 12, 2018 at 6:22 AM Christie, Marcus Aaron <mailto:machr...@iu.edu>> wrote: > Hi Dimuthu, > > Thanks for cleaning things up! However, I'm pretty sure we're still using > db-event-manager to manage our event-based synchronization between Airavata > services. > > The rest looks good to be removed though. > > Thanks, > > Marcus > >> On Dec 10, 2018, at 1:08 AM, DImuthu Upeksha > <mailto:dimuthu.upeks...@gmail.com>> wrote: >> >> Hi Folks, >> >> I removed following modules on staging branch [1] and created a separate >> branch named archive to keep old changes. >> >> allocation-manager >> cloud >> db-event-manager >> gfac >> integration-tests >> monitoring >> test-suite >> workflow >> workflow-model >> xbaya >> xbaya-gui >> >> Following modules were kept as there are some dependencies to other modules >> >> compute-account-provisioning >> configuration >> security >> >> Updated repository was tested in the Testing environment and everything >> seems to be running smoothly. I will redeploy Staging setup in few days and >> merge changes to develop branch as well. >> >> Thanks >> Dimuthu >> >> [1] https://github.com/apache/airavata/tree/staging/modules >> <https://github.com/apache/airavata/tree/staging/modules> >> >> On Fri, Nov 30, 2018 at 8:32 PM Suresh Marru > <mailto:sma...@apache.org>> wrote: >> Hi Sudhakar, >> >> The allocation manager from last year contributions is here - >> https://github.com/apache/airavata-sandbox/tree/master/allocation-manager >> <https://github.com/apache/airavata-sandbox/tree/master/allocation-manager> >> the one Dimuthu is suggesting to clean up is a stale one. >> >> I think we should turn the allocation manager into a larger goal of >> enforcing quotas mainly for user storage and probably take on as soon as >> possible. >> >> Cheers, >> Suresh >> >>> On Nov 30, 2018, at 8:37 AM, Pamidighantam, Sudhakar V >>> mailto:spami...@illinois.edu>> wrote: >>> >>> What is the estimated timeline for enforceable allocation management to be >>> available in Airavata, 2019, 2020? >>> >>> Thanks, >>> Sudhakar. >>> >>> From: DImuthu Upeksha >> <mailto:dimuthu.upeks...@gmail.com>> >>> Reply-To: "dev@airavata.apache.org <mailto:dev@airavata.apache.org>" >>> mailto:dev@airavata.apache.org>> >>> Date: Friday, November 30, 2018 at 8:30 AM >>> To: "dev@airavata.apache.org <mailto:dev@airavata.apache.org>" >>> mailto:dev@airavata.apache.org>> >>> Subject: Re: Unused modules >>> >>> Hi Suresh, >>> >>> +1 for removing gfac modules as well >>> >>> Dimuthu >>> >>> On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata >> <mailto:smarru.apa...@gmail.com>> wrote: >>> +1 to remove all of them. While you are at it, should we also remove gfac >>> modules from develop and staging branches? >>> >>> Suresh >>> >>> >>> On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha >> <mailto:dimuthu.upeks...@gmail.com>> wrote: >>> >>> Hi Folks, >>> >>> I can see that some modules [1] are no longer being used or actively >>> developed. >>> >>> allocation-manager >>> cloud >>> compute-account-provisioning >>> configuration >>> db-event-manager >>> integration-tests >>> monitoring >>> security >>> workflow >>> workflow-model >>> xbaya >>> xbaya-gui >>> >>> I'm suggesting to remove these unused modules as they affect the build time >>> and the clarity of the code. Any objections / suggestions? >>> >>> [1] https://github.com/apache/airavata/tree/staging/modules >>> <https://github.com/apache/airavata/tree/staging/modules> >>> >>> Thanks >>> Dimuthu >> > smime.p7s Description: S/MIME cryptographic signature
Re: Unused modules
Hi Marcus, Thanks for raising this issue. Is that a runtime dependency? For me, everything compiled without db-event-manager [1]. Can you point me to the place where we are using that? [1] https://travis-ci.org/apache/airavata/builds/465830628 Thanks, Dimuthu On Wed, Dec 12, 2018 at 6:22 AM Christie, Marcus Aaron wrote: > Hi Dimuthu, > > Thanks for cleaning things up! However, I'm pretty sure we're still using > db-event-manager to manage our event-based synchronization between Airavata > services. > > The rest looks good to be removed though. > > Thanks, > > Marcus > > On Dec 10, 2018, at 1:08 AM, DImuthu Upeksha > wrote: > > Hi Folks, > > I removed following modules on staging branch [1] and created a separate > branch named archive to keep old changes. > > allocation-manager > cloud > db-event-manager > gfac > integration-tests > monitoring > test-suite > workflow > workflow-model > xbaya > xbaya-gui > > Following modules were kept as there are some dependencies to other modules > > compute-account-provisioning > configuration > security > > Updated repository was tested in the Testing environment and everything > seems to be running smoothly. I will redeploy Staging setup in few days and > merge changes to develop branch as well. > > Thanks > Dimuthu > > [1] https://github.com/apache/airavata/tree/staging/modules > > On Fri, Nov 30, 2018 at 8:32 PM Suresh Marru wrote: > >> Hi Sudhakar, >> >> The allocation manager from last year contributions is here - >> https://github.com/apache/airavata-sandbox/tree/master/allocation-manager the >> one Dimuthu is suggesting to clean up is a stale one. >> >> I think we should turn the allocation manager into a larger goal of >> enforcing quotas mainly for user storage and probably take on as soon as >> possible. >> >> Cheers, >> Suresh >> >> On Nov 30, 2018, at 8:37 AM, Pamidighantam, Sudhakar V < >> spami...@illinois.edu> wrote: >> >> What is the estimated timeline for enforceable allocation management to >> be available in Airavata, 2019, 2020? >> >> Thanks, >> Sudhakar. >> >> *From: *DImuthu Upeksha >> *Reply-To: *"dev@airavata.apache.org" >> *Date: *Friday, November 30, 2018 at 8:30 AM >> *To: *"dev@airavata.apache.org" >> *Subject: *Re: Unused modules >> >> Hi Suresh, >> >> +1 for removing gfac modules as well >> >> Dimuthu >> >> On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata >> wrote: >> >> +1 to remove all of them. While you are at it, should we also remove gfac >> modules from develop and staging branches? >> >> Suresh >> >> >> >> On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha >> wrote: >> >> Hi Folks, >> >> I can see that some modules [1] are no longer being used or actively >> developed. >> >> allocation-manager >> cloud >> compute-account-provisioning >> configuration >> db-event-manager >> integration-tests >> monitoring >> security >> workflow >> workflow-model >> xbaya >> xbaya-gui >> >> I'm suggesting to remove these unused modules as they affect the build >> time and the clarity of the code. Any objections / suggestions? >> >> [1] https://github.com/apache/airavata/tree/staging/modules >> >> Thanks >> Dimuthu >> >> >> >
Re: Unused modules
Hi Dimuthu, Thanks for cleaning things up! However, I'm pretty sure we're still using db-event-manager to manage our event-based synchronization between Airavata services. The rest looks good to be removed though. Thanks, Marcus > On Dec 10, 2018, at 1:08 AM, DImuthu Upeksha > wrote: > > Hi Folks, > > I removed following modules on staging branch [1] and created a separate > branch named archive to keep old changes. > > allocation-manager > cloud > db-event-manager > gfac > integration-tests > monitoring > test-suite > workflow > workflow-model > xbaya > xbaya-gui > > Following modules were kept as there are some dependencies to other modules > > compute-account-provisioning > configuration > security > > Updated repository was tested in the Testing environment and everything seems > to be running smoothly. I will redeploy Staging setup in few days and merge > changes to develop branch as well. > > Thanks > Dimuthu > > [1] https://github.com/apache/airavata/tree/staging/modules > <https://github.com/apache/airavata/tree/staging/modules> > > On Fri, Nov 30, 2018 at 8:32 PM Suresh Marru <mailto:sma...@apache.org>> wrote: > Hi Sudhakar, > > The allocation manager from last year contributions is here - > https://github.com/apache/airavata-sandbox/tree/master/allocation-manager > <https://github.com/apache/airavata-sandbox/tree/master/allocation-manager> > the one Dimuthu is suggesting to clean up is a stale one. > > I think we should turn the allocation manager into a larger goal of enforcing > quotas mainly for user storage and probably take on as soon as possible. > > Cheers, > Suresh > >> On Nov 30, 2018, at 8:37 AM, Pamidighantam, Sudhakar V >> mailto:spami...@illinois.edu>> wrote: >> >> What is the estimated timeline for enforceable allocation management to be >> available in Airavata, 2019, 2020? >> >> Thanks, >> Sudhakar. >> >> From: DImuthu Upeksha > <mailto:dimuthu.upeks...@gmail.com>> >> Reply-To: "dev@airavata.apache.org <mailto:dev@airavata.apache.org>" >> mailto:dev@airavata.apache.org>> >> Date: Friday, November 30, 2018 at 8:30 AM >> To: "dev@airavata.apache.org <mailto:dev@airavata.apache.org>" >> mailto:dev@airavata.apache.org>> >> Subject: Re: Unused modules >> >> Hi Suresh, >> >> +1 for removing gfac modules as well >> >> Dimuthu >> >> On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata > <mailto:smarru.apa...@gmail.com>> wrote: >> +1 to remove all of them. While you are at it, should we also remove gfac >> modules from develop and staging branches? >> >> Suresh >> >> >> On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha > <mailto:dimuthu.upeks...@gmail.com>> wrote: >> >> Hi Folks, >> >> I can see that some modules [1] are no longer being used or actively >> developed. >> >> allocation-manager >> cloud >> compute-account-provisioning >> configuration >> db-event-manager >> integration-tests >> monitoring >> security >> workflow >> workflow-model >> xbaya >> xbaya-gui >> >> I'm suggesting to remove these unused modules as they affect the build time >> and the clarity of the code. Any objections / suggestions? >> >> [1] https://github.com/apache/airavata/tree/staging/modules >> <https://github.com/apache/airavata/tree/staging/modules> >> >> Thanks >> Dimuthu > smime.p7s Description: S/MIME cryptographic signature
Re: Unused modules
Hi Folks, I removed following modules on staging branch [1] and created a separate branch named archive to keep old changes. allocation-manager cloud db-event-manager gfac integration-tests monitoring test-suite workflow workflow-model xbaya xbaya-gui Following modules were kept as there are some dependencies to other modules compute-account-provisioning configuration security Updated repository was tested in the Testing environment and everything seems to be running smoothly. I will redeploy Staging setup in few days and merge changes to develop branch as well. Thanks Dimuthu [1] https://github.com/apache/airavata/tree/staging/modules On Fri, Nov 30, 2018 at 8:32 PM Suresh Marru wrote: > Hi Sudhakar, > > The allocation manager from last year contributions is here - > https://github.com/apache/airavata-sandbox/tree/master/allocation-manager the > one Dimuthu is suggesting to clean up is a stale one. > > I think we should turn the allocation manager into a larger goal of > enforcing quotas mainly for user storage and probably take on as soon as > possible. > > Cheers, > Suresh > > On Nov 30, 2018, at 8:37 AM, Pamidighantam, Sudhakar V < > spami...@illinois.edu> wrote: > > What is the estimated timeline for enforceable allocation management to be > available in Airavata, 2019, 2020? > > Thanks, > Sudhakar. > > *From: *DImuthu Upeksha > *Reply-To: *"dev@airavata.apache.org" > *Date: *Friday, November 30, 2018 at 8:30 AM > *To: *"dev@airavata.apache.org" > *Subject: *Re: Unused modules > > Hi Suresh, > > +1 for removing gfac modules as well > > Dimuthu > > On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata > wrote: > > +1 to remove all of them. While you are at it, should we also remove gfac > modules from develop and staging branches? > > Suresh > > > > On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha > wrote: > > Hi Folks, > > I can see that some modules [1] are no longer being used or actively > developed. > > allocation-manager > cloud > compute-account-provisioning > configuration > db-event-manager > integration-tests > monitoring > security > workflow > workflow-model > xbaya > xbaya-gui > > I'm suggesting to remove these unused modules as they affect the build > time and the clarity of the code. Any objections / suggestions? > > [1] https://github.com/apache/airavata/tree/staging/modules > > Thanks > Dimuthu > > >
Re: Unused modules
Hi Sudhakar, The allocation manager from last year contributions is here - https://github.com/apache/airavata-sandbox/tree/master/allocation-manager <https://github.com/apache/airavata-sandbox/tree/master/allocation-manager> the one Dimuthu is suggesting to clean up is a stale one. I think we should turn the allocation manager into a larger goal of enforcing quotas mainly for user storage and probably take on as soon as possible. Cheers, Suresh > On Nov 30, 2018, at 8:37 AM, Pamidighantam, Sudhakar V > wrote: > > What is the estimated timeline for enforceable allocation management to be > available in Airavata, 2019, 2020? > > Thanks, > Sudhakar. > > From: DImuthu Upeksha > Reply-To: "dev@airavata.apache.org" > Date: Friday, November 30, 2018 at 8:30 AM > To: "dev@airavata.apache.org" > Subject: Re: Unused modules > > Hi Suresh, > > +1 for removing gfac modules as well > > Dimuthu > > On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata <mailto:smarru.apa...@gmail.com>> wrote: > +1 to remove all of them. While you are at it, should we also remove gfac > modules from develop and staging branches? > > Suresh > > > On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha <mailto:dimuthu.upeks...@gmail.com>> wrote: > > Hi Folks, > > I can see that some modules [1] are no longer being used or actively > developed. > > allocation-manager > cloud > compute-account-provisioning > configuration > db-event-manager > integration-tests > monitoring > security > workflow > workflow-model > xbaya > xbaya-gui > > I'm suggesting to remove these unused modules as they affect the build time > and the clarity of the code. Any objections / suggestions? > > [1] https://github.com/apache/airavata/tree/staging/modules > <https://github.com/apache/airavata/tree/staging/modules> > > Thanks > Dimuthu
Re: Unused modules
Can you move these to an “archive” directory or make an “archive” branch? It may be useful to easily find these for future reference. Marlon From: "dimuthu.upeks...@gmail.com" Reply-To: dev Date: Friday, November 30, 2018 at 8:29 AM To: dev Subject: Re: Unused modules Hi Suresh, +1 for removing gfac modules as well Dimuthu On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata wrote: +1 to remove all of them. While you are at it, should we also remove gfac modules from develop and staging branches? Suresh On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha wrote: Hi Folks, I can see that some modules [1] are no longer being used or actively developed. allocation-manager cloud compute-account-provisioning configuration db-event-manager integration-tests monitoring security workflow workflow-model xbaya xbaya-gui I'm suggesting to remove these unused modules as they affect the build time and the clarity of the code. Any objections / suggestions? [1] https://github.com/apache/airavata/tree/staging/modules Thanks Dimuthu smime.p7s Description: S/MIME cryptographic signature
Re: Unused modules
What is the estimated timeline for enforceable allocation management to be available in Airavata, 2019, 2020? Thanks, Sudhakar. From: DImuthu Upeksha Reply-To: "dev@airavata.apache.org" Date: Friday, November 30, 2018 at 8:30 AM To: "dev@airavata.apache.org" Subject: Re: Unused modules Hi Suresh, +1 for removing gfac modules as well Dimuthu On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata mailto:smarru.apa...@gmail.com>> wrote: +1 to remove all of them. While you are at it, should we also remove gfac modules from develop and staging branches? Suresh On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha mailto:dimuthu.upeks...@gmail.com>> wrote: Hi Folks, I can see that some modules [1] are no longer being used or actively developed. allocation-manager cloud compute-account-provisioning configuration db-event-manager integration-tests monitoring security workflow workflow-model xbaya xbaya-gui I'm suggesting to remove these unused modules as they affect the build time and the clarity of the code. Any objections / suggestions? [1] https://github.com/apache/airavata/tree/staging/modules Thanks Dimuthu
Re: Unused modules
Hi Suresh, +1 for removing gfac modules as well Dimuthu On Fri, Nov 30, 2018 at 6:32 PM Apache Airavata wrote: > +1 to remove all of them. While you are at it, should we also remove gfac > modules from develop and staging branches? > > Suresh > > > On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha > wrote: > > Hi Folks, > > I can see that some modules [1] are no longer being used or actively > developed. > > allocation-manager > cloud > compute-account-provisioning > configuration > db-event-manager > integration-tests > monitoring > security > workflow > workflow-model > xbaya > xbaya-gui > > I'm suggesting to remove these unused modules as they affect the build > time and the clarity of the code. Any objections / suggestions? > > [1] https://github.com/apache/airavata/tree/staging/modules > > Thanks > Dimuthu > >
Re: Unused modules
+1 to remove all of them. While you are at it, should we also remove gfac modules from develop and staging branches? Suresh > On Nov 30, 2018, at 6:44 AM, DImuthu Upeksha > wrote: > > Hi Folks, > > I can see that some modules [1] are no longer being used or actively > developed. > > allocation-manager > cloud > compute-account-provisioning > configuration > db-event-manager > integration-tests > monitoring > security > workflow > workflow-model > xbaya > xbaya-gui > > I'm suggesting to remove these unused modules as they affect the build time > and the clarity of the code. Any objections / suggestions? > > [1] https://github.com/apache/airavata/tree/staging/modules > > Thanks > Dimuthu >
Unused modules
Hi Folks, I can see that some modules [1] are no longer being used or actively developed. allocation-manager cloud compute-account-provisioning configuration db-event-manager integration-tests monitoring security workflow workflow-model xbaya xbaya-gui I'm suggesting to remove these unused modules as they affect the build time and the clarity of the code. Any objections / suggestions? [1] https://github.com/apache/airavata/tree/staging/modules Thanks Dimuthu
Re: Remove unused modules to local antic or any other place?
Well the debatable topic is: we have lot of potential features like EC2 submisisons which need to come back. But I agree, when they are not being maintained, leaving in the code just for the sake of it has a cost. I am + 1 for tagging the current master (for easy retrieval in future) and deleting all the un-maintained pieces. And slowly build back from minimal features based on user demand and the components we commit to maintain. Suresh On May 8, 2015, at 8:35 AM, Pierce, Marlon marpi...@iu.edu wrote: Another possibility is to just delete them, since they are in the git repo in case we ever need to go back. Marlon From: Shameera Rathnayaka shameerai...@gmail.com mailto:shameerai...@gmail.com Reply-To: dev@airavata.apache.org mailto:dev@airavata.apache.org dev@airavata.apache.org mailto:dev@airavata.apache.org Date: Thursday, May 7, 2015 at 11:12 PM To: dev dev@airavata.apache.org mailto:dev@airavata.apache.org Subject: Remove unused modules to local antic or any other place? Hi Team, When i try to do the refactoring, I am facing some issues with other deprecated gfac-modules. For an example, If I need to add a method for a common interface (like GfacProvider), I need to implement all subclasses in those deprecated modules. ( yes i can just leave it blank, but why we need to waste time on that? and this will complicate git commits too). What is the verdict on this? Thanks, Shameera. -- Best Regards, Shameera Rathnayaka. email: shameera AT apache.org http://apache.org/ , shameerainfo AT gmail.com http://gmail.com/ Blog : http://shameerarathnayaka.blogspot.com/ http://shameerarathnayaka.blogspot.com/
Re: Remove unused modules to local antic or any other place?
Another possibility is to just delete them, since they are in the git repo in case we ever need to go back. Marlon From: Shameera Rathnayaka shameerai...@gmail.commailto:shameerai...@gmail.com Reply-To: dev@airavata.apache.orgmailto:dev@airavata.apache.org dev@airavata.apache.orgmailto:dev@airavata.apache.org Date: Thursday, May 7, 2015 at 11:12 PM To: dev dev@airavata.apache.orgmailto:dev@airavata.apache.org Subject: Remove unused modules to local antic or any other place? Hi Team, When i try to do the refactoring, I am facing some issues with other deprecated gfac-modules. For an example, If I need to add a method for a common interface (like GfacProvider), I need to implement all subclasses in those deprecated modules. ( yes i can just leave it blank, but why we need to waste time on that? and this will complicate git commits too). What is the verdict on this? Thanks, Shameera. -- Best Regards, Shameera Rathnayaka. email: shameera AT apache.orghttp://apache.org , shameerainfo AT gmail.comhttp://gmail.com Blog : http://shameerarathnayaka.blogspot.com/
Remove unused modules to local antic or any other place?
Hi Team, When i try to do the refactoring, I am facing some issues with other deprecated gfac-modules. For an example, If I need to add a method for a common interface (like GfacProvider), I need to implement all subclasses in those deprecated modules. ( yes i can just leave it blank, but why we need to waste time on that? and this will complicate git commits too). What is the verdict on this? Thanks, Shameera. -- Best Regards, Shameera Rathnayaka. email: shameera AT apache.org , shameerainfo AT gmail.com Blog : http://shameerarathnayaka.blogspot.com/
[jira] [Commented] (AIRAVATA-1124) Cleaning up unused modules in the trunk for 0.12 release
[ https://issues.apache.org/jira/browse/AIRAVATA-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968634#comment-13968634 ] ASF subversion and git services commented on AIRAVATA-1124: --- Commit 0e2c10f568f583d886657ad0b536ae62f7fa04ad in airavata's branch refs/heads/master from [~samindaw] [ https://git-wip-us.apache.org/repos/asf?p=airavata.git;h=0e2c10f ] AIRAVATA-1124 Cleaning up unused modules in the trunk for 0.12 release Key: AIRAVATA-1124 URL: https://issues.apache.org/jira/browse/AIRAVATA-1124 Project: Airavata Issue Type: Task Affects Versions: 0.12 Reporter: Saminda Wijeratne Assignee: Saminda Wijeratne Fix For: 0.12 This JIRA task is created in accordance with the airavata-dev list mail [1] for cleaning up maven modules out of the Apache Airavata trunk. 1. http://markmail.org/message/wtpufpxbjabtyntx#query:+page:1+mid:i2jlwhsqnnjd57g2+state:results -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Cleaning up unused modules before the 0.12 release
]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.comwrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules/ws-messenger/message-monitor modules/ws-messenger/messagebox modules/ws-messenger/messagebroker modules/ws-messenger/samples modules/rest/client modules/rest/mapping modules/rest/service modules/rest/webapp I think we should not ship these unused code in the release. Either we have to fix the trunk by moving these code to sandbox or to another branch or we have to branch 0.12 without these modules and make airavata compile and work and then release 0.12. WDYT ? Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University
Re: Cleaning up unused modules before the 0.12 release
|---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.comwrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules/ws-messenger/message-monitor modules/ws-messenger/messagebox modules/ws-messenger/messagebroker modules/ws-messenger/samples modules/rest/client modules/rest/mapping modules/rest/service modules/rest/webapp I think we should not ship these unused code in the release. Either we have to fix the trunk by moving these code to sandbox or to another branch or we have to branch 0.12 without these modules and make airavata compile and work and then release 0.12. WDYT ? Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University -- Thanks, Sachith Withana -- System Analyst Programmer PTI Lab Indiana University
[jira] [Resolved] (AIRAVATA-1124) Cleaning up unused modules in the trunk for 0.12 release
[ https://issues.apache.org/jira/browse/AIRAVATA-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saminda Wijeratne resolved AIRAVATA-1124. - Resolution: Fixed security, xbaya-gui, ws-messenger/messagebox, ws-messenger/messagebroker modules will not be removed. the logic of removing the modules is to remove any modules which we will not need now or in the future and remove any module which will cause confusion to a user who will download the source of this release (eg: unused distrobutions, broken samples). Cleaning up unused modules in the trunk for 0.12 release Key: AIRAVATA-1124 URL: https://issues.apache.org/jira/browse/AIRAVATA-1124 Project: Airavata Issue Type: Task Affects Versions: 0.12 Reporter: Saminda Wijeratne Assignee: Saminda Wijeratne Fix For: 0.12 This JIRA task is created in accordance with the airavata-dev list mail [1] for cleaning up maven modules out of the Apache Airavata trunk. 1. http://markmail.org/message/wtpufpxbjabtyntx#query:+page:1+mid:i2jlwhsqnnjd57g2+state:results -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Cleaning up unused modules before the 0.12 release
On Sun, Apr 13, 2014 at 12:45 AM, Saminda Wijeratne samin...@gmail.comwrote: 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 samin...@gmail.comwrote: 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 swsach...@gmail.comwrote: Since Modules like ws-messenger,xbaya and the workflow-interpreter will be re-integrated to Airavata, is it possible for us to just remove these modules in a 0.12 release branch and ship the source without these modules? BUT keep those in the trunk, since it will be re-integrated? So the release branch wouldn't have unused code but the trunk will. Also +1 to deleting the Rest module. On Thu, Apr 10, 2014 at 10:43 AM, Saminda Wijeratne samin...@gmail.comwrote: - If the code hadn't changed since last release theoretically speaking, we should be able to build each module which we moved to attic individually (with the version set to 0.11) because the maven repo should have its dependencies. - Other option what Marlon suggested as I understood is to attic all other dependent modules (atleast a copy of it to the attic) along with the parent POM and all. This might cause some conflicts related to modules that are in the actual trunk if someone decides to work in both trunk and attic. wdyt is the best way to go? (or any other approaches?) On Thu, Apr 10, 2014 at 4:02 AM, Marlon Pierce marpi...@iu.edu wrote: The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.comwrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +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
[jira] [Commented] (AIRAVATA-1124) Cleaning up unused modules in the trunk for 0.12 release
[ https://issues.apache.org/jira/browse/AIRAVATA-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967998#comment-13967998 ] Saminda Wijeratne commented on AIRAVATA-1124: - 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]. |-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 [REMOVE] |-samples [REMOVE] |-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 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 Cleaning up unused modules in the trunk for 0.12 release Key: AIRAVATA-1124 URL: https://issues.apache.org/jira/browse/AIRAVATA-1124 Project: Airavata Issue Type: Task Affects Versions: 0.12 Reporter: Saminda Wijeratne Assignee: Saminda Wijeratne Fix For: 0.12 This JIRA task is created in accordance with the airavata-dev list mail [1] for cleaning up maven modules out of the Apache Airavata trunk. 1. http://markmail.org/message/wtpufpxbjabtyntx#query:+page:1+mid:i2jlwhsqnnjd57g2+state:results -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (AIRAVATA-1124) Cleaning up unused modules in the trunk for 0.12 release
[ https://issues.apache.org/jira/browse/AIRAVATA-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967998#comment-13967998 ] Saminda Wijeratne edited comment on AIRAVATA-1124 at 4/14/14 5:32 AM: -- 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]. |-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 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 was (Author: samindaw): 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]. |-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 [REMOVE] |-samples [REMOVE] |-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 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 Cleaning up unused modules in the trunk for 0.12 release Key: AIRAVATA-1124
Re: Cleaning up unused modules before the 0.12 release
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 samin...@gmail.comwrote: 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 swsach...@gmail.comwrote: Since Modules like ws-messenger,xbaya and the workflow-interpreter will be re-integrated to Airavata, is it possible for us to just remove these modules in a 0.12 release branch and ship the source without these modules? BUT keep those in the trunk, since it will be re-integrated? So the release branch wouldn't have unused code but the trunk will. Also +1 to deleting the Rest module. On Thu, Apr 10, 2014 at 10:43 AM, Saminda Wijeratne samin...@gmail.comwrote: - If the code hadn't changed since last release theoretically speaking, we should be able to build each module which we moved to attic individually (with the version set to 0.11) because the maven repo should have its dependencies. - Other option what Marlon suggested as I understood is to attic all other dependent modules (atleast a copy of it to the attic) along with the parent POM and all. This might cause some conflicts related to modules that are in the actual trunk if someone decides to work in both trunk and attic. wdyt is the best way to go? (or any other approaches?) On Thu, Apr 10, 2014 at 4:02 AM, Marlon Pierce marpi...@iu.edu wrote: The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.com wrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +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
Re: Cleaning up unused modules before the 0.12 release
Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.comwrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules/ws-messenger/message-monitor modules/ws-messenger/messagebox modules/ws-messenger/messagebroker modules/ws-messenger/samples modules/rest/client modules/rest/mapping modules/rest/service modules/rest/webapp I think we should not ship these unused code in the release. Either we have to fix the trunk by moving these code to sandbox or to another branch or we have to branch 0.12 without these modules and make airavata compile and work and then release 0.12. WDYT ? Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University
Re: Cleaning up unused modules before the 0.12 release
The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.comwrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules/ws-messenger/message-monitor modules/ws-messenger/messagebox modules/ws-messenger/messagebroker modules/ws-messenger/samples modules/rest/client modules/rest/mapping modules/rest/service modules/rest/webapp I think we should not ship these unused code in the release. Either we have to fix the trunk by moving these code to sandbox or to another branch or we have to branch 0.12 without these modules and make airavata compile and work and then release 0.12. WDYT ? Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University
Re: Cleaning up unused modules before the 0.12 release
- If the code hadn't changed since last release theoretically speaking, we should be able to build each module which we moved to attic individually (with the version set to 0.11) because the maven repo should have its dependencies. - Other option what Marlon suggested as I understood is to attic all other dependent modules (atleast a copy of it to the attic) along with the parent POM and all. This might cause some conflicts related to modules that are in the actual trunk if someone decides to work in both trunk and attic. wdyt is the best way to go? (or any other approaches?) On Thu, Apr 10, 2014 at 4:02 AM, Marlon Pierce marpi...@iu.edu wrote: The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.com wrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.com wrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules
Re: Cleaning up unused modules before the 0.12 release
Since Modules like ws-messenger,xbaya and the workflow-interpreter will be re-integrated to Airavata, is it possible for us to just remove these modules in a 0.12 release branch and ship the source without these modules? BUT keep those in the trunk, since it will be re-integrated? So the release branch wouldn't have unused code but the trunk will. Also +1 to deleting the Rest module. On Thu, Apr 10, 2014 at 10:43 AM, Saminda Wijeratne samin...@gmail.comwrote: - If the code hadn't changed since last release theoretically speaking, we should be able to build each module which we moved to attic individually (with the version set to 0.11) because the maven repo should have its dependencies. - Other option what Marlon suggested as I understood is to attic all other dependent modules (atleast a copy of it to the attic) along with the parent POM and all. This might cause some conflicts related to modules that are in the actual trunk if someone decides to work in both trunk and attic. wdyt is the best way to go? (or any other approaches?) On Thu, Apr 10, 2014 at 4:02 AM, Marlon Pierce marpi...@iu.edu wrote: The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.com wrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.com wrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like
Re: Cleaning up unused modules before the 0.12 release
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 swsach...@gmail.comwrote: Since Modules like ws-messenger,xbaya and the workflow-interpreter will be re-integrated to Airavata, is it possible for us to just remove these modules in a 0.12 release branch and ship the source without these modules? BUT keep those in the trunk, since it will be re-integrated? So the release branch wouldn't have unused code but the trunk will. Also +1 to deleting the Rest module. On Thu, Apr 10, 2014 at 10:43 AM, Saminda Wijeratne samin...@gmail.comwrote: - If the code hadn't changed since last release theoretically speaking, we should be able to build each module which we moved to attic individually (with the version set to 0.11) because the maven repo should have its dependencies. - Other option what Marlon suggested as I understood is to attic all other dependent modules (atleast a copy of it to the attic) along with the parent POM and all. This might cause some conflicts related to modules that are in the actual trunk if someone decides to work in both trunk and attic. wdyt is the best way to go? (or any other approaches?) On Thu, Apr 10, 2014 at 4:02 AM, Marlon Pierce marpi...@iu.edu wrote: The code in the attic should be buildable as much as possible, so how about an attic POM? Marlon On 4/10/14 2:09 AM, Saminda Wijeratne wrote: Following are the list of modules that is currently present in the trunk. I've tagged the ones that I'll be removing from trunk as [REMOVE] and the ones that will be moved to the airavata attic[1] as [ATTIC] as recommended by Marlon in a JIRA [2]. I'd be grateful if you could please review. |-modules |---commons |-utils |-json *[REMOVE]* |-workflow-execution-context |-gfac-schema |-workflow-tracking |---security *[REMOVE][ATTIC]* |---server |---rest *[REMOVE]* |-client |-webapp |-mappings |-service |---configuration |-server |-client |---orchestrator |-orchestrator-core |-airavata-orchestrator-service |-orchestrator-client-sdks |---ws-messenger |-messagebroker *[REMOVE][ATTIC]* |-commons |-messagebox *[REMOVE]**[ATTIC]* |-client |-distribution |-message-monitor |---test-suite |---workflow-model |-workflow-model-component-node *[REMOVE]* |-workflow-model-core |-workflow-model-component *[REMOVE]* |---xbaya-gui *[REMOVE][ATTIC]* |---registry |-airavata-registry-test *[REMOVE]* |-airavata-jpa-registry |-registry-api |-registry-cpi |-airavata-registry-service *[REMOVE]* |---credential-store |---integration-tests |---distribution |-airavata-server |-xbaya-gui *[REMOVE]* |-release |-airavata-client |---gfac |-gfac-core |-gfac-ec2 |-gfac-monitor |---airavata-client |---workflow-interpreter *[REMOVE]* |-airavata-api |---airavata-model-utils |---airavata-api-server |---airavata-api-stubs |---airavata-data-models |---airavata-client-sdks |-java-client-samples |-tools |---job-monitor |---registry-tool |---gsissh |---phoebus-integration |-samples *[REMOVE]* |---simple-math-service |---sample-gateway |---levenshtein-distance-service |---provenance-registry-handler |---gateway-developer-guide |---echo-service |---distribution |---airavata-client |-create-application |-workflow-run |---complex-math-service Thanks, Saminda 1. https://svn.apache.org/repos/asf/airavata/attic 2. https://issues.apache.org/jira/browse/AIRAVATA-1137 On Mon, Apr 7, 2014 at 4:00 PM, Saminda Wijeratne samin...@gmail.com wrote: Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +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
[jira] [Created] (AIRAVATA-1124) Cleaning up unused modules in the trunk for 0.12 release
Saminda Wijeratne created AIRAVATA-1124: --- Summary: Cleaning up unused modules in the trunk for 0.12 release Key: AIRAVATA-1124 URL: https://issues.apache.org/jira/browse/AIRAVATA-1124 Project: Airavata Issue Type: Task Affects Versions: 0.12 Reporter: Saminda Wijeratne Assignee: Saminda Wijeratne Fix For: 0.12 This JIRA task is created in accordance with the airavata-dev list mail [1] for cleaning up maven modules out of the Apache Airavata trunk. 1. http://markmail.org/message/wtpufpxbjabtyntx#query:+page:1+mid:i2jlwhsqnnjd57g2+state:results -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Cleaning up unused modules before the 0.12 release
Hi Devs, Any final decision on this? I created a JIRA[1] to track this. If no objections for my previous suggestion, tomorrow I'll go ahead and remove the unused modules from the Airavata trunk and update the pom.xmls and assembly files (delete any links to the modules whether they are commented or not). 1. https://issues.apache.org/jira/browse/AIRAVATA-1124 On Mon, Mar 31, 2014 at 9:21 AM, Saminda Wijeratne samin...@gmail.comwrote: +1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules/ws-messenger/message-monitor modules/ws-messenger/messagebox modules/ws-messenger/messagebroker modules/ws-messenger/samples modules/rest/client modules/rest/mapping modules/rest/service modules/rest/webapp I think we should not ship these unused code in the release. Either we have to fix the trunk by moving these code to sandbox or to another branch or we have to branch 0.12 without these modules and make airavata compile and work and then release 0.12. WDYT ? Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University
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
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
Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules/ws-messenger/message-monitor modules/ws-messenger/messagebox modules/ws-messenger/messagebroker modules/ws-messenger/samples modules/rest/client modules/rest/mapping modules/rest/service modules/rest/webapp I think we should not ship these unused code in the release. Either we have to fix the trunk by moving these code to sandbox or to another branch or we have to branch 0.12 without these modules and make airavata compile and work and then release 0.12. WDYT ? Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University
Re: Cleaning up unused modules before the 0.12 release
+1 for deleting the Rest module. Generally I'm inclined towards keeping the other modules since they'll be needed in future and if we remove them now and add them later they will loose their commit history. That being said, we sort of did that already when we moved to git recently. Thus this could be one rare situation deleting at this point is justified? On Mon, Mar 31, 2014 at 10:22 AM, Suresh Marru sma...@apache.org wrote: Lahiru, I see two parts of this cleanup. The modules we will integrate back in the near future and the ones we will deprecate for good. I vote for deleting the ones like the registry rest modules and keep the ones like xbaya, interpreter and ws-messenger. Suresh On Mar 31, 2014, at 10:10 AM, Lahiru Gunathilake glah...@gmail.com wrote: Hi All, In 0.12 release we are not using following modules and what is our plan on these modules. Are we going to ship this sources with 0.12 release ? modules/xbaya modules/workflow-interpreter modules/ws-messenger/client modules/ws-messenger/commons modules/ws-messenger/distribution modules/ws-messenger/message-monitor modules/ws-messenger/messagebox modules/ws-messenger/messagebroker modules/ws-messenger/samples modules/rest/client modules/rest/mapping modules/rest/service modules/rest/webapp I think we should not ship these unused code in the release. Either we have to fix the trunk by moving these code to sandbox or to another branch or we have to branch 0.12 without these modules and make airavata compile and work and then release 0.12. WDYT ? Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University
