[
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.
Creation of core module
-----------------------
Key: JBIDE-3897
URL:
https://jira.jboss.org/jira/browse/JBIDE-3897
Project: Tools (JBoss Tools)
Issue Type: Task
Components: core
Affects Versions: 3.1.0.M1
Reporter: Rob Stryker
Assignee: Rob Stryker
Fix For: 3.1.0.M3
Time to recreate the core module. Tasks are as follows:
1) The module folder, with plugins / features / test category
2) an (empty) test plugin
3) an empty core plugin
4) an empty ui plugin
5) a feature
6) properly added into build
7) properly added to build download page
8) properly added to update site
The purpose of this module will be to hold common well-designed multi-functional classes
that will be usable by others. This will help reduce dependencies between modules by
providing a common base.
--
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