[ https://issues.jboss.org/browse/JBIDE-8474?page=com.atlassian.jira.plugin... ] Rob Stryker commented on JBIDE-8474: ------------------------------------ There are some things that made this patch very difficult to create and merge. Some of those items are listed below, along with how to avoid them in future merges. These coding practices should be used for all patches to trunk, just *in case* the patch later has to be backported to maintenance. 1) Constants have been removed. The appropriate action here is to mark the constant as deprecated and remove references to it, but the constant should *REMAIN* in the file it was in. (ex: ICloudElementFilter) 2) The entire class structure of some classes have changed. This has destroyed the class heirarchy for many subclasses. An example of this is as follows: -public class InstanceUnmarshaller extends AbstractActionAwareUnmarshaller<Instance, InstanceAction> { +public class InstanceUnmarshaller extends AbstractActionAwareUnmarshaller<Instance> { By changing the structure of AbstractActionAwareUnmarshaller, all subclasses also must change. This is a big breaking change that makes merging with a maintenance stream especially difficult. 3) Deletion of Files. In general, all files that should be deleted should rather be marked @Deprecated. Deletion of classes in maintenance stream is not really encouraged. (Ex: FieldMatcher and others) 4) Deletion of used enums (inside Instance.InstanceState) 5) Removal of methods in a superclass. In general, these methods should be marked @Deprecated instead 6) Addition of abstract methods to an abstract superclass (forcing subclasses to add stub implementations) or additions to an interface WITHOUT adding a default method to an abstract implementer (also forcing all subclasses to add these methods) 7) Changing the return type of a method. In general, a new method should be added, and the old method should be marked deprecated. Admittedly deltacloud is fairly new but these kinds of API changes must be done carefully in the future. You must make sure to keep classes and method signatures the same. In the event that drastic changes must be made, you should create a new class and deprecate the old, add a new method and deprecate the old, etc. Other things that were *not* issues and are OK are: 1) Addition of new classes. This is fine. (ex: LoadCloudInstancesJob etc) 2) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8474?page=com.atlassian.jira.plugin... ] Rob Stryker commented on JBIDE-8474: ------------------------------------ I'm not sure I can fully endorse this patch. There seems to be a *lot* of work done in trunk that is not relevant to branch. I really really think we should re-implement the required patches for branch in the smallest way possible, and get moving forward on big changes to trunk. Trunk needs extensive changes, huge re-design, a client plugin, etc etc etc. Even if we accept this patch to branch, we will end up redesigning trunk substantially. After that, any new patches to trunk will not be relevant to branch anymore and will require custom backports anyway. So I think we should skip the pretending and just recognize that trunk needs huge changes. We should fix branch as small and effectively as possible, but get to work on the *real* digging to make sure trunk becomes what it needs to. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8474?page=com.atlassian.jira.plugin... ] Vlado Pakan closed JBIDE-8474. ------------------------------ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira