Hi Brian No need, to hijack a thread, just start a new thread. But no problem, threads of conversation can stray.
Will this extension registry work with stand alone ArgoUML or is it specific to argoeclipse? I believe we are all agreed to move ArgoUML to the eclipse platform but I don't think the period of this GSOC will achieve that and would still expect that ArgoUML will run standalone. I would like to know that work to reorganise the plug-in architecture will work for both stand-alone ArgoUML and argoeclipse. Regards Bob. On 06/04/2008, Brian Hudson <[EMAIL PROTECTED]> wrote: > 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] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
