[ https://issues.jboss.org/browse/JBIDE-12469?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-12469: ------------------------------------- 1) Explain the scope of the new plugin. This scope will be binding throughout the life of the plugin. This scope must be specific enough to avoid dumping-ground plugins tht grow with no limit, but also not be so restrictive as to make the plugin so narrowly defined that it is not useful. The scope of this plugin is to be the lowest-level plugin in JBoss Tools. The plugin will be a common base that all core plugins can depend on to make a home for utility classes relating to the core eclipse platform. An attachment (in progress) is provided for plugins that may be a dependency for this plugin. Any utility class in need of a home and potentially useful to many components may live here. In the event that the project begins to fill up, for example with a utility model that grows larger than expected, such a model may possibly be broken out into a new home to keep this baseline plugin thin, streamlined, and useful for every component. 2) Is there any other plugin in the same component with an overlapping scope? If so, which plugins? Currently, org.jboss.tools.common.core has many classes that seem to overlap with the mission of this plugin. It is expected that relevant classes will move down into this new plugin. Package names will be maintained where appropriate in order to smooth the transition. 3) If there is an overlap, is there some technical reason the new plugin or feature is required? org.jboss.tools.common is flooded with UI code. As we cannot simply remove the UI portions without causing consuming components a large problem, creating a new core component and then filling it with useful utilities is the suggested solution. 4) If there is no technical reason for the new plugin, would the code fit more appropriately inside an existing plugin instead? N/A, technical reason listed above 5) What is the expected size of the plugin, now and in the future. (ie, one or two classes to provide a dialog to the user, or, many classes providing a model for xyz and will grow as new features are added, or, unlimited home for all utilities depending on (some subset) of eclipse packages. ) The expected size of the plugin is unknown at this time. It is expected that approximately 60-70% of org.jboss.tools.common will move into this new plugin, but the scope allows for the plugin to grow more so long as the dependency requirements are met (no mylyn, no svn deps, no cvs deps, no team deps, no rse deps, no UI deps, etc). 6) What bundles / products will this new plugin require? (webtools, gef, astools, org.eclipse.team, etc) An attached file lists all dependencies that are within scope, though initially the number of dependencies will be much smaller. 7) Give a brief technical overview. This is an attempt to begin core / UI separation of the common component, starting with it's lowest plugin. All files will be svn move'd to the new location to preserve history. All files will be moved to an identical package name in the new plugin to preserve upstream component's compilation requirements. org.jboss.tools.common will then depend on org.jboss.tools.common.core and re-exported to also ensure that consuming plugins do not need to add a dependency at this time. Seeking approvals. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12469?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-12469: ------------------------------------- I would also like to add that ASTools (as.core) would like to depend on this new common.core plugin as soon as possible, as would JMX Tools and possibly project archives. Having a core plugin to put utilities that is not mixed with UI is the only reason so far astools has resisted depending on common. This has led to me not moving code that *could* be used by others into common. I have resisted because moving my code into common would force a UI dependency on astools and jmx tools. So I see this as a great and important first step. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12469?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-12469: ------------------------------------- It will add ambiguity for sure. The problem is that splitting the bundle and renaming the package will break basically every single part of the jboss tools build, until every single component updates all their imports. This is obviously something that simply cannot be done. The only other option I can imagine would be as follows: 1) Create the new o.j.t.common.core plugin 2) Copy all relevent classes into o.j.t.common.core with o.j.t.common.core package names 3) do not delete the o.j.t.common varients, but mark them as @deprecated and make them extend the new plugin (deleting the body of the class) I am fairly certain Max (and others) will not agree to this strategy, as it leaves about 40-45 class "stubs" that are deprecated and who's sole purpose is to sit there with an @Deprecated marker. Webtools typically does something like this though. They would sooner introduce a new class in a new package, make the old class extend the new one, mark the old one as @Deprecated, and, perhaps a year later, remove the old stub class. But from my experiences with the project, many people will see a big problem with this idea. Many members of the team do not like having empty stub classes with identical names sit around useless, cluttering up their views and complicating their ctrl+shift+t open-type hotkeys. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12469?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-12469: ------------------------------------- <dgolovin> I agree, not so much time for package renaming, m1 = split, m2 = rename should work Max Rydahl Andersen: +1 for getting the split done sooner rather than later. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12469?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-12469: -------------------------------- Attachment: JBIDE-12469.v1.patch.txt patch for the common change -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12469?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-12469. --------------------------------- Resolution: Done I have committed the patch. A notice was sent to jbt-dev list. There is no new feature; the plugin was added to the lowest feature in the common component for now. I would like to break this out, though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira