Hello all, I wanted to review all the work that has been done until now, some issues should be clarified. I've looked at how are structured the Eclipse plugins and Subclipse.
I think that the architecture of ArgoEclipse completely right, 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. - 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. - 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. - 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. - argoeclipse-feature : The same. - argoeclipse-update-site : The same. - argoeclipse-www : This would be the same as "ArgoEclipse Web Site". There is nothing wrong with ArgoEclipse Web Site, the function should be the same, but the name I think is not standard. All other plugins/projects are in small caps and in the form "argoeclipse-xxx", this small caps useage is common for all Eclipse standard plugins also. - argoeclipse-doc : For future documents. Maybe this is not necessary, because ArgoUML is the main actor here, so the docs would be links to ArgoUML documentation with additional explanations for things that are different in ArgoEclipse. Eclipse uses a form of access filter for packages from plugins. For example if we access a a class from a plugin that is located in a path like this org.eclipse.core.internal.content.XMLContentDescriber you get a warning "Discouraged access: The type XMLContentDescriber is not accessible due to restriction on required project org.eclipse.core.contenttype" or if you access a class from a package named *.forbidden.* you get an error. 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. The packages org.argouml.argoeclipse.core.* do you think it's OK to be shorter like org.argoeclipse.*? I'm not sure about this. Some notes about the content of the packages in the plugin. This is mainly my fault. The plugin.properties file (where the strings are defined for usage) should be broke into properties files for every major package. The classes should have exact single responsibilities, and shouldn't have lots of lines. So the PluginModel should be broke. The warnings should be minimals, there are a lots of warnings right now. Better comments and only where are needed. Help integration in all the main dialogs/wizards. Any comments and suggestions are appreciated. Cheers, Bogdan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
