*"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." * I agree that fixing this should be a goal. Here is a quote from a session at JavaONE this year called Converting (Large) Applications to OSGi:
*"... Many applications have been forced to develop their own plug-in system, and these systems, particularly, tend to conflict with strong modularity. A key pitfall in moving systems to OSGi is overmodularizing an existing application. A better approach is usually to turn the existing system into a single module and then gradually move parts of it to other bundles."* This type of incremental approach is what I'm suggesting. On Sun, Apr 6, 2008 at 2:00 PM, Tom Morris <[EMAIL PROTECTED]> wrote: > 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] > >
