Bogdan wrote: > I think ... we should have these projects: > > - argoeclipse-argouml : This should stay the same, a wrapper > of ArgoUML, with additional changes to interact well with the > other projects/plugins. This should depend on > org.eclipse.osgi, but it's not necessary.
Over time (perhaps a _long_ time) this will hopefully become multiple plugins with separate plugins for the core ArgoUML, different model subsystems (MDR, EMF, etc), different language plugins (Java, C#, PHP, etc). The ArgoUML core, when it becomes more modular, should also be lighter weight without unnecessary Swing or standalone ArgoUML application framework stuff. > - argoeclipse-core : My opinion is that this should be just a > core, model, business logic component. All the plugins from > Eclipse are built this way, they have a "core" part and a > "ui" part. This should depend like it does on > aroeclipse-argouml, and should contain the framework for the > plugin, all non-GUI stuff. Some included > dependencies: org.eclipse.core.runtime, > org.eclipse.core.resources and other non-GUI plugins. Should > have extension points, so other people could implement other > GUI plugins if they want, or just extend the current functionality. Sounds good. > - argoeclipse-ui : Should depend on argoeclipse-core. This > would be the plugin responsible for all the GUI stuff. I > don't know if this should have extension points. I think it's better to have too few rather than too many extension points to start with. If there are obvious places for people to extend things we can add extension points, otherwise we should wait until they are requested or there's a clear need. > - argoeclipse-help : This should be the plugin responsible > with the help system additions. I think that is good to > separate the plugins, this would make the project more > structured. I sow this in Subclipse also. Sounds good. > - argoeclipse-www : This would be the same as "ArgoEclipse > Web Site". I agree. This can be renamed. > - argoeclipse-doc : I don't see a need for this right now. > We should use too these conventions: paths like *.internal.* and > *.forbidden.* are reserved for internal use only, other > plugins that want to extend our functionality should have > access to the API we defined outside of the internal > packages. The user can configure not to show up these > warnings/errors, but it's a recommendation from us that we > will support the standard API (not internal) and also we will > have a better structure. We definitely want to be very clear about what is a public API and what isn't. The public API should only be as big as necessary because the larger the surface area, the more work it is to maintain. > The packages org.argouml.argoeclipse.core.* do you think it's > OK to be shorter like org.argoeclipse.*? I'm not sure about this. Let's defer this for the time being. A shorter package name would be nice, but we really should register an org.argoeclipse domain to be able to use that namespace. > The plugin.properties file (where > the strings are defined for usage) should be broke into > properties files for every major package. I agree. > So the PluginModel should be broke[n up]. Yes, this is getting too big. It's in danger of becoming to ArgoEclipse what ProjectBrowser is to ArgoUML. :-) Feel free to go ahead and start working on these refactorings, but let's do them incrementally, one at a time, rather than all in one big change. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
