Community
Participate
Working Groups
Public types that are used by the framework have API that use CF Java client types. Example is: AbstractApplicationDelegate One of the problems with this is that the CF Java client may change (e.g. v1 -> v2), and have breaking changes, like different type names, and therefore the client type changes will also break the public CFT API. The CFT public API should be independent of the underlying client to avoid these breaking scenarios. We should consider making this change before joining release train, as the number of CFT adopters are still low.
We will aim to get this finished for Neon M7 after CFT is in the Neon aggregate build (Neon M6).
v1 CF client types that need to be removed from public API, and replaced with CFT-defined wrappers with equivalent information: CORE: 1. AbstractApplicationDelegate: org.cloudfoundry.client.lib.archive.ApplicationArchive; org.cloudfoundry.client.lib.domain.CloudApplication; Considerations: - ApplicationArchive wrapper only needs to return a file for now, or we can change delegate API to only return File as the archive - CloudApplication is used in a public static. Maybe we can move public static into an internal util if we don’t want to wrap CloudApplication at this stage 2. ApplicationDeploymentInfo: org.cloudfoundry.client.lib.domain.CloudService; org.cloudfoundry.client.lib.domain.Staging; Considerations: - Staging is just used for buildpack. Maybe change public API to just set/get buildpack for now, rather than define wrapper for Staging. UI: 1. ICloudFoundryServiceWizardIconProvider org.cloudfoundry.client.lib.domain.CloudServiceOffering
GitHub Pull Request 21 created by [nierajsingh] https://github.com/eclipse/cft/pull/21
To summarise the v1 work that was completed with the Pull Request that was merged into CFT master: - CloudFoundryApplicationModule and CloudFoundryServer were replaced with IModule and IServer in all public API - v1 type ApplicationArchive replaced with CFT type CFApplicationArchive - v1 type CloudService replaced with CFT type CFServiceInstance - v1 type CloudServiceOffering replaced with CFT type CFServiceOffering - v1 type CloudServicePlan replaced with CFT type CFServicePlan - Removal of Orgs and Spaces from public API as it was used only in a utility method that could be kept internal In large part, the new CFT types that model the old v1 types retain most of the old information. Some changes include removal of "vendor" from Services as this is deprecated and does not return any values for Pivotal. However, if needed by BlueMix, we can add it back. Other considerations: CFServiceInstance, CFServiceOffering, and CFServicePlan are still internal, but they do not refer to any v1 types or any other internal types. Should we make these public?
A couple of questions/comments: 1. For org.eclipse.cft.server.core.CFApplicationArchive, the getName() and getEntries() are protected methods. Is there a particular reasons for those to be protected or they should really be public. Those are basic info of an application archive so I would expect most people who are using those method need to access those. 2. For CFServiceInstance, CFServiceOffering, and CFServicePlan, I agree those can be moved to the public. Those classes are standard ones that can easily be used by adoptors. 3. For the removal of "vendor" from Services, Bluemix does not currently use it at all so I am ok for not having it on the new API. 4. The constructor of org.eclipse.cft.server.core.internal.client.CFClientV1Support is passing in CloudInfoDiego object which I find it a bit strange. I would expect the remaining V1 client support is more for DEA functions. Is this class for the supporting Diego using the V1 client and that's why we have the Diego object passed in? Is there any usage of that class that is on DEA scenario?
Thanks for the feedback. All the changes have now been pushed into master: 1. Made CFApplicationArchive API public 2. Moved the new client-neutral services type into public package 3. Refactored the target framework to take in a generic CFInfo rather than the Diego-specific CloudDiegoInfo Also moved EnvironmentVariable to public package since it has no v1 references and it is used in another public API.
