[ https://jira.jboss.org/jira/browse/JBIDE-3897?page=com.atlassian.jira.plu... ] Nick Boldt reassigned JBIDE-3897: --------------------------------- Assignee: Max Rydahl Andersen (was: Nick Boldt) Not sure what needs to be in this common component. Perhaps this is better assigned to someone with a better sense of what is "common" across the tools? Also, I don't feel comfortable refactoring others' code, so maybe this should be split into 17 issues, one per component, such that everyone refactors their own base to pull out common tests/functionality/classes/libs/strings/UI pieces? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-3897?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-3897: --------------------------------------- Fix Version/s: 3.1.0.M3 (was: 3.1.0.M2) Assignee: Rob Stryker (was: Max Rydahl Andersen) Rob - i'm not sure what it is you want here ? creating a empty plugin seems a bit weird ? Didn't you have something specific you wanted in it ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-3897?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-3897: ------------------------------------ As one example of this: People are still reaching into as.classpath.core to extend an abstract classpath container who's purpose was to expose HARD-CODED libraries EMBEDDED inside the plugin as jars. Almost all of these extenders are NOT using the key two methods which provide this functionality and are instead providing their own entries, and so basically, they're all extending this class for no reason whatsoever. They're extending it to basically use as a stub implementation of the parent interface (which is NOT in my code) but they override the key methods which have any real functionality. In several cases, they actually add a dependency to my module JUST to use this class... which would be fine if they were using the class to provide classpath entries to hard-coded jar files stored inside the plugin, but they're not. They're just using it as a stub and extending the methods with any logic. I've argued many times that since they're not actually using any of the methods that provide any logic, they should simply create their own implementation for the stub methods. Max has disagreed several times. Apparently he thinks that because my class provides a getter and a setter it's magically worth creating dependencies between modules for. If there is to be a such thing as an AbstractClasspathContainer which provides logic others would like to use, it should not be in the AS plugin, first of all. Second of all it should be actually designed with the proper logic people wish to have access to. And quite frankly I think we need some standards as to when you extend a class and when you make your own. Is a simply getter / setter combination enough "logic" to make extending the preferred behavior instead of, oh, idk, making your own getter / setter? Currently it's just people reaching willy nilly into other modules and classes and overriding 95% of the logic, thus creating dependencies between modules when there's absolutely no reason for there to be any. There's also the case of people extending things that are not actually fit for their use at all, but since max says it's better to extend than copy even 1 method, they do that. If there is a set of functionality a class provides and it's commonly requested by several of the team, it should be in a common location. And currently, the "common" module is not that location as the common module (as Sean has rightly pointed out) is scary. There needs to be cleanup. A new core module where people can properly engineer new widely-used classes, classpath containers, abstract parents, and other such things, should be added... as well as a testing plugin which provides all of the most common scenerios (project copying, etc) without having dependencies on other projects or modules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-3897?page=com.atlassian.jira.plu... ] Rob Stryker resolved JBIDE-3897. -------------------------------- Resolution: Won't Fix whatever. we can do this if there's ever a real abundance of repetition or people get really annoyed about fat fingers -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira