ArgoUML has modules (the ArgoUML's terminology for its plugins), as an extension mechanism of the application. The more common use case are the programming language modules, but, you can also have core modules, like for instance the sequence diagram module or the UML property panels module. The problem with the ArgoUML modules as I see it now is that ArgoUML is reinventing the wheel and that this wheel has it share of limitations.
- One of the biggest limitations is the problem of not being able to specify a dependency of one module of another.
- Another problem is that it is a bit of work to define a module which only purpose is to integrate a third party library into ArgoUML.
- The final thing I dislike is that for one reason or another, currently the installation of ArgoUML includes all standard modules in the classpath by generating a hard-coded list of the jars (see
argouml.jarin a installation of ArgoUML).
My idea is that we should base our modules or plugins in OSGi. I think that this isn't very hard to achieve because the current scheme doesn't differ very much from what plain OSGi requires. In part this was performed by necessity of the Argoeclipse project – definition of the Eclipse build system based on the MANIFEST.MF files. But, the other part is simply due to the usage of good object oriented design with the Java language, which is related to the interface involved in the definition of the base module (see
) and of specific interfaces for functionality oriented modules, like for instance