One of the problems with the current ArgoUML module system is that is monolithic. There's only one type of module and they have a flat dependency structure. That's something that we definitely want to fix when migrating to Eclipse.
On Sun, Apr 6, 2008 at 8:43 AM, Bob Tarling <[EMAIL PROTECTED]> wrote: > Will this extension registry work with stand alone ArgoUML or is it > specific to argoeclipse? My approach to this would be to use an Eclipse RCP based solution as the standalone ArgoUML. > On 06/04/2008, Brian Hudson <[EMAIL PROTECTED]> wrote (commenting on > statements by Bob in quotes): > > "Breaking the main project up into modules this way fits far better with > > eclipse architecture." > > This is true to an extent. Eclipse does break things down into module > plug-ins, but the granularity of this is really up to the developers. Doing > this at the ArgoUML subsytem level is probably a good place to start. We've already got a starting point in ArgoEclipse, so it's worth studying that to begin with. The next steps are to: a) add missing functionality (e.g. plugin modules) and b) continue breaking larger plugins (e.g. entire Diagram subsystem in one plugin) into smaller plugins (e.g. plugins per Diagram type with lower level plugins with basic diagram functionality). > > "...most of our subsystems don't have a defined API." > > When breaking out these subsystems it would probably be a good time to > address this. Eclipse plug-ins support a notion of published versus internal > APIs which may help with this. Taking full advantage of the Extension > Registry will tend to force us to have more well defined APIs as we begin to > define extension points and extensions. A more fundamental issue than internal vs. external APIs is the constraint that the dependency graph must be a directed acyclic graph. We know there are places where this is an issue with the current ArgoUML code (cyclic dependencies). > > "Where the modules architecture helps our subsystem is in dependancies. A > > subsystem like sequence diagram needs to be dependant on the core > > application but we don't want any cyclic references with the main > > application being aware of sequence diagram. But we do somehow need > > the core application to become aware of the sequence diagrams at runtime > in > > order to present the correct "New Sequence Diagram" button etc." > > This is exactly the kind of thing the Eclipse Extension Registry is perfect > for. A subsystem like sequence diagram would express its dependency on on > the core via the plugin.xml. The core/ui would have something like a > "NewWizard" extension point defined. The sequence diagram plug-in would > provide an extension to this "NewWizard" extension point. At runtime the > core/ui could then query the Extension Registry for extensions of its > "NewWizard" extension point and show the correct New Wizard menu item or > what not (the Extension Registry also handles the instantiation of needed > classes)... the underlying code for this need not even be invoked until its > actually needed because the name of the menu item and its icon etc can be > expressed right in the plugin.xml. This is actually exactly how the New > Wizards in Eclipse work. Just in case it isn't obvious to folks, this extension mechanism can (and would) also be used to add new menu items to popup menus (New->Sequence Diagram), buttons to toolbars, etc, so there will often be multiple integration points for new bits of functionality. > > "We will need a way to define modules that are core modules as opposed to > > external/optional modules which is all we have at the moment." The whole point of the Eclipse plugin architecture is that there AREN'T any core plugins. Other than the OSGi framework and some basic bootstrapping functionality for the plugin architecture itself, everything is optional/replaceable. What functionality gets bundled and what is optional is a decision that can be deferred until release planning time. If someone wants to package a Sequence Diagram only version of ArgoUML, they should be able to start with the sequence diagram plugin and iteratively resolve all the dependencies in its dependency graph and package just those plugins together with the OSGI core. From a practical point of view, the basics which included in the Eclipse RCP platform (online help, update mechanism, etc) probably form the base upon which we build. I'm not sure it even makes sense to try and do an Eclipse version of our current module API because the model is basically "you can use any global API that you can find (and if it's not global, make it global)." This won't work in the more disciplined Eclipse environment. The majority of our plugins are designed to support specific programming languages with code generators and reverse engineering modules, so it might make more sense to define Eclipse extension points for these two pieces of functionality (and the associated preferences settings) and then move on to the more complex cases. Converting the bundled Java code generation and reverse engineering to plugins could happen as part of this as well. Things like the DB module or the new Sequence diagrams are going to be much more invasive and difficult to handle without some substantial refactoring of the current code. It may not be feasible to support plugins of this style until we have the ArgoUML core split into a finer grained set of plugins with the appropriate extension points exposed, so that core work would need to get done before tackling them. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
