cloudfoundry/eclipse-integration-cloudfoundry — pull request #8 by elsony (2014-05-27 18:57:32+00:00)
Title: [72048132] Define public APIs for adopters

I have merged with the latest in the repository before submitting this pull request.
A couple of things to note:
1. Adopter branding plugin needs to reference some classes in their branding plugin. However, they probably don't need to actually accessing or overriding the class. Therefore, I just added comment to the class for not moving or renaming so we don't have to expose on external package.
2. .internal package has the convention of .internal, e.g. org.cloudfoundry.ide.eclipse.internal.server.core should be renamed to org.cloudfoundry.ide.eclipse.server.core.internal. So the external packages will shows first on development environment. Some plugin is already using that convention, e.g. org.cloudfoundry.ide.eclipse.server.standalone. Do you want me to rename internal packages that doesn't follow the convention?
3. One class that I haven't really moved to external package yet is org.cloudfoundry.ide.eclipse.internal.server.core.client.CloudFoundryApplicationModule. It has been used all over the place. I have created a ICloudFoundryApplicationModule but chances are we need to expose more methods for that class. I'll do that on a change set.
4. I moved JavaWebApplicationWizardDelegate to the public package org.cloudfoundry.ide.eclipse.server.ui since I find most of the deployment have very similar dialog. Therefore, I just expose that to avoid exposing the internal wizard pages itself. I can't think of a better name so I leave it as the current name. Feel free to rename.