On Mon, Apr 7, 2008 at 12:23 PM, Brian Hudson <[EMAIL PROTECTED]> wrote: > "... A key pitfall in moving systems to OSGi is overmodularizing an existing > application. A better approach is usually to turn the existing system into a > single module and then gradually move parts of it to other bundles."
Well, I'd be the last one to recommend *over*-anything! I always favor just the right amount. :-) The approach you describe is basically what we used during the 2006 Google Summer of Code and set us on the path that we're headed down now. Currently we're in the "gradually move parts of it to other bundles" phase. The current structure is that org.argouml.argoeclipse.core depends on org.argouml.app, org.argouml.model, and org.argouml.model.mdr, but they, as well as their bundled libraries, are really treated as a single whole. Additionally, we use some tricks to defeat Eclipse's dependency management so things that depend on up-level references like Tigris' GEF will work in the Eclipse environment. The UI plugin org.argouml.argoeclipse.ui then builds on this core plugin to offer various views, actions, perspectives, etc. Additional plugins provide help (skeletal), product branding for standalone (ie RCP) deployment, etc. I know that this seems like 11th hour feedback in the context of GSoC, but we can work to fine tune your proposal. Two prime candidates for the definition of extension points are the Model subsystem, which already has a cleanly defined API, and the ArgoUML plugin modules. For modules, the current mechanism of using ModuleInterface to mark modules should be made redundant by services provided by OSGi/Eclipse. It is primarily a marker interface and some administrative machinery and using it would defeat one of the primary reasons for using the plugin.xml mechanism (ie defer class loading until absolutely necessary). It may, however, be desirable to have a special new style (v3) plugin which knows how to find and load old-style (v2) ArgoUML modules. (I'm using v2 & v3, because we had an earlier module loader and I don't want to get the "new"s and "old"s confused). Code generation plugins (we currently have 7 of them) implement the ModuleInterface and org.argouml.uml.generator.CodeGenerator interfaces. In the new structure, I'd see an extension point based on, and replacing, CodeGenerator with any ModuleInterface functionality not provided by OSGi also absorbed into the new extension point. Reverse engineering plugins (Java, Java .class, C++, IDL, Python) would be similarly treated, substituting the org.argouml.uml.reveng.ImportInterface for CodeGenerator. Of course, in the Eclipse context, there are already extension points for reverse engineering and code generation (at least for Java using EMF), so it would be worth investigating whether any of this work can be leveraged. I suspect it may be too divergent from our existing world view to be terribly useful. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
