no... its an optional tool... and Sorry Marlon I just noticed what you meant... I had refactored the phoebus code to a new module but forgotten to remove it from gfac-core. I'll do that now... It shouldn't affect the current build.
On Wed, Oct 23, 2013 at 11:30 AM, Lahiru Gunathilake <[email protected]>wrote: > Did we ever used this in any release ? > > > On Wed, Oct 23, 2013 at 12:43 AM, Saminda Wijeratne <[email protected]>wrote: > >> Code in phoebus implements the SPI of the GridFTP configuration >> management interface in GFac. It is meant to be a pluggable library to >> Airavata. It serves as an example for the implementation of the SPI and one >> of the outcomes of my research with Dr. Martin Swany. Since this was done >> last year I will verify if it adhere's to the new implementation of the >> specific GFac provider. >> >> >> On Tue, Oct 22, 2013 at 2:49 PM, Marlon Pierce <[email protected]> wrote: >> >>> This is different from the gfac ec2 provider code--code in ec2/ and >>> phoebus/ don't seem to be connected to anything. >>> >>> >>> Marlon >>> >>> On 10/22/13 2:29 PM, Lahiru Gunathilake wrote: >>> > We need to pull out all the implementations from gfac-core and leave >>> teh >>> > core classes only in gfac-core and have separate modules for all the >>> > implementation each has a dependency to gfac-core module. >>> > >>> > ex: gfac-ec2, gfac-gram,gfac-gsissh, gfac-ssh etc. >>> > >>> > Regards >>> > Lahiru >>> > >>> > >>> > >>> > >>> > On Tue, Oct 22, 2013 at 2:07 PM, Marlon Pierce <[email protected]> >>> wrote: >>> > >>> >> The classes in >>> >> modules/gfac-core/src/main/java/org/apache/airavata/gfac/ec2/ don't >>> >> look connected to anything else in GFAC. If this is the case, they >>> >> should be moved out of the GFAC trunk. What is a good location? >>> >> >>> >> >>> >> Marlon >>> >> >>> >> >>> > >>> >>> >> > > > -- > System Analyst Programmer > PTI Lab > Indiana University >
