Does ArgoVersion reference other classes? I suspect it doesn't, which means that there aren't any dependency cycles involving it. Putting it in its own package or a catch-all utility package will make things appear a little bit neater at the package level, but the real work, at least in my opinion, is to break the actual class dependency cycles that are throughout ArgoUML.
It will definitely be harder to tease apart ProjectBrowser and some of the other rats' nests, but until we do we won't have a significant impact on improving the structure of the system. Tom > -----Original Message----- > From: Michiel van der Wulp [mailto:[EMAIL PROTECTED] > Sent: Saturday, April 21, 2007 1:02 PM > To: [email protected] > Subject: [argouml-dev] Detangling ArgoUML's dependency web... > > > Hi All, > > One other thought about my effort to work on dependencies: > The easiest thing to do, is find the packages at the complete > "top" and at > the "bottom", so that is what I started with. > > The latter I talked about in my previous mail, but the top > package/subsystem > is org.argouml.application, i.e. the Application subsystem, > according the > cookbook. > > That would mean, that the ArgoVersion class does not belong in this > package...since it is used in many places all over ArgoUML, > and even by a > few plugins. > Can we move this class? (And where to?) > > Regards, > Michiel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
