Just a reminder before I go ahead and do this before the seq2 module goes live I intend to rearchitect the packages as such
org.argouml.core.diagrams.sequence2.module - The module class to register with framework org.argouml.core.diagrams.sequence2.diagram - The sequence2 extension of the diagrams subsystem org.argouml.core.diagrams.sequence2.proppanel - The sequence2 proppanel The intention is that at a later date there is likely to be org.argouml.core.diagrams.sequence2.cognitive - Critics for sequence2 org.argouml.core.diagrams.sequence2.reveng - Reverse engineering code for sequence diagrams This keeps our subsystems clearly separated within the seq2 module. Regards Bob. 2008/5/2 Bob Tarling <[EMAIL PROTECTED]>: > I've just come across another subsystem that diagram modules will want > to plug in to. Toms recent commit to RESequenceDiagramDialog reminded > me. > > When class diagrams are extracted they will also need to plugin to the > reverse engineering subsystem. We'll need some common way for diagram > modules to extend and allow themselves to built as part of the > reverse engineering process. I was planning on leaving class diagrams > till last anyway so we have some time to think about that. > > Again, using sequence2 as an example we currently require > > org.argouml.core.diagrams.sequence2.module - The module class to > register with framework > org.argouml.core.diagrams.sequence2.diagram - The sequence2 extension > of the diagrams subsystem > org.argouml.core.diagrams.sequence2.proppanel - The sequence2 proppanel > org.argouml.core.diagrams.sequence2.cognitive - Critics for sequence2 > org.argouml.core.diagrams.sequence2.reveng - Reverse engineering code > for sequence diagrams > > > Bob. > > > > 2008/5/2 Bob Tarling <[EMAIL PROTECTED]>: >> I'll rename the sequence2 package soons so let me know if anyone >> disagrees with my suggestion. >> >> I've just realised that some diagram modules will want to register >> critics so we will in theory also need >> org.argouml.core.diagrams.sequence2.cognitive >> >> Are we happy that this pattern is used for packages as other diagrams >> are extracted? >> >> Bob. >> >> >> >> 2008/5/1 Bob Tarling <[EMAIL PROTECTED]>: >> >> >> > The new sequence diagram implementation proves how easy it is to keep >> > a particular diagram type within its own clear subsystem as a separate >> > eclipse project loaded at runtime as a plugin. >> > >> > I'd like to go ahead and do this with the other diagram types. I think >> > the more we begin to move stuff out of argouml-app the clearer it will >> > be how to move the rest. >> > >> > Initially I'd just like to move the packages in their current >> > structure but eventually I'd like to refactor into a flatter package >> > structure. >> > >> > The sequence diagrams I should be able to refactor sooner rather than >> > later though. I'll use that as an example of what I'd like to see >> > >> > First of all I'd like the base package structure to echo our new >> > naming convention >> > >> > So we will have >> > >> > org.argouml.core.diagrams.sequence2 >> > >> > In that base package I would expect no classes >> > >> > The subpackages would contain the implementations >> > >> > org.argouml.core.diagrams.sequence2.plugin - The module class >> > org.argouml.core.diagrams.sequence2.diagram - The sequence2 extension >> > of the diagrams subsystem >> > org.argouml.core.diagrams.sequence2.proppanel - The sequence2 >> > extension of the proppanels subsystem >> > >> > >> > We seem to use the term module and plugin interchangeably. Could we >> > settle on one. I would suggest plugin as it tends to fit eclipse >> > terminology better. >> > >> > Bob. >> > >> > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=979840 To unsubscribe from this discussion, e-mail: [EMAIL PROTECTED]
