It involves ArgoUML directly, though it does have a side benefit of making ArgoEclipse a little easier.
As I'm sure you know, Eclipse is heavily plug-in based. Really all Eclipse is is a small kernel that launches the Extension Registry. At runtime the Eclipse kernel starts the Extension Registry and EVERYTHING is then contributed via plug-ins. In the proposal I suggest modifying the Module Loader subsystem to use the Extension Registry. The ModuleLoader will define a *module* extension point which modules would implement an *extension* to. Each module then creates a plugin.xml file (Eclipse PDE has excellent tooling for this), and it would specify that it extends the *module* *extension point*. One of the required attributes in this *extension points* schema would be a Java class which implements the existing ModuleInterface (which all modules already do). This lets us take advantages of some of the features of the Extension Registry (dependency loading etc), while making it very simple to update existing modules to the existing architecture. The ModuleLoader could also define an *extension point *called *DetailsTab*which would allow a module to contribute one or more detail tabs... as opposed to locating them via reflection like is done now. Alternatively, the ModuleLoader could define an *extension point* called *DetalsTabProvider*which would require an *extension* to specify a class which implements *DetailsTabProvider* which is similar to how it works now. Something along these lines could also be done with settings tabs. With this completed I suggest taking a look at where else the Extension Registry could be utilized. Subsystems are an obvious choice. There are a lot of possibilities here, a bunch of areas could benefit from this integration. As subsystems are continually refined, and begin defining their own extension points I would imagine that the ModuleLoader subsystem would eventually be phased out, with ArgoUML core starting the the Extension Registry and loading all the plugins itself... but this is beyond the scope of GSoC of course =) On Sun, Apr 6, 2008 at 8:43 AM, Bob Tarling <[EMAIL PROTECTED]> wrote: > 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] > >
