Not trying to hijack the thread here but Bob made some comments that relate pretty closely to some of the motivations for my GSoC proposal. In proposal I propose modifying the existing Module Loader subsytem to utilize the Eclipse Extension Registry and then once that is complete, to take a look at how it may be utilized with ArgoUMLs concept of subsystems.
*"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. *"...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*. *"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. *"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." * I'm not sure how explicitly this would need to be defined if ArgoUML were to move to using the Eclipse Extension Registry. Eclipse plug-ins tend to do this by naming there plug-ins something along the lines of org.argouml.core.*, maybe something like this would be sufficient?* * If you haven't seen my proposal it can be reviewed here: http://www.hudsonb.com/GSoC/08/argouml_proposal.pdf Brian On Sat, Apr 5, 2008 at 7:53 PM, Bob Tarling <[EMAIL PROTECTED]> wrote: > I would suggest both (c) and (d). > > I would suggest as soon as possible. I think it was originally delayed > waiting until a release takes place first. We had no idea it would > take so long till the next release happens and we have no real > guarantees now. Lets not wait. > > I think that putting this into the repository as a module has some > benefits. > > We have a concept of subsystems (often a one to one relationship to > the subcomponents in IZ). But most of our subsystems don't have a > defined API. Instead many of the subsystem are within the main > project/jar which is argouml-core > > To place this into svn as a separate eclipse project shows it clearly > as a separate subsystem physically. I would hope we can then follow on > similarly with the other diagrams. > > I've been trying to find the email with lack of success so far but I > have seen mentioned somewhere that the concept of breaking the main > project up into modules this way fits far better with eclipse > architecture. Parts of the application are discovered at runtime. > > Whether we release the new sequence diagrams as part of the next > release I think is a separate matter and should not be part of this > decision to bring the source into the ArgoUML project. By having this > as a module then the decision to include it in a release later will > require hardly any change, just a change in the build script. > > 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. > > 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. > > Bob. > > > > \ > On 05/04/2008, Christian López Espínola <[EMAIL PROTECTED]> wrote: > > Hi, > > > > This week I have some holidays, so I planned to work on the sequence > > diagrams and merge them into the trunk, so they'll have more > > visibility, you'll blame at me, and I'll be more motivated to work on > > them. > > > > BTW, we have a release plan again and a repository restructure, so I > > wonder what should I do. We have some options: > > a) Wait until the release to integrate them on the svn repos (It's not > > ready for a release, but maybe source code could be on trunk by then) > > b) Wait until the svn repos restructuring. > > c) Do it ASAP > > d) Leave it as a module (this doesn't like me, because it won't be > seen) > > > > I'd like to get feedback from you until Wednesday/Thursday, when I'll > > be able to work on it. > > > > TIA. > > > > -- > > Regards, > > > > > > Christian López Espínola > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
