There's a pending reorganization of the ArgoUML project structure which will address some, if not all, of these issues. There current project structure is an artifact of the requirement that Eclipse projects have non-overlapping source trees. That requirement has since been relaxed (I think), so it might be possible to fix the Eclipse projects without having to reorganize the directory structure.
Most of the problems that I've seen can be hacked around by two adjustments: 1) moving the GEF library into the main ArgoUML project and 2) making argouml-core-model-mdr depending on argouml-core-model rather than the other way around. > - it throws errors when the user is trying to open a zargo > file or create a new one with the new wizard. The PGML parser in the GEF library requires access to the main Argo classes during the parsing process, but that requires an up-level reference in the dependency tree which isn't legal for Eclipse plugins. Fix #1 above resolves this. > - Log4j doesn't work. (log4j:WARN No appenders could be found > for logger <some class>. log4j:WARN Please initialize the > log4j system properly.) I've looked at the Log4J initialization recently to figure out why it's not working for Java Web Start environments and it looks like it could have some issues with how it uses class loaders. That could be the problem here or it could be another issue with up-level references. > - The model MDR implementation doesn't work the "ArgoUML > standard way", the client (eg ArgoEclipse) must instantiate > the MDRModelImplementation and then sets the Model to use the > MDR implementation. I'm not sure that the ArgoUML "standard way" isn't wrong. It's basically set up to *require* a cyclic dependency between Model and Model-MDR. The only reason that source analyers don't detect the cyclical dependency is that it's hidden as a class name encoded in a string literal which is used to dynamically load at runtime. > - The static blocks of code from classes, that should run > when the class is initially accessed from argouml* doesn't work. I'm not sure what's causing that. > - do not split ArgoUML in projects argouml* in Eclipse (that are also > plugins) or > - remove all of these cyclic dependencies, and adjust the > static initialization blocks from classes (essentially copying them in > ArgoEclipse) I'd prefer to see the ArgoUML project structure for Eclipse projects follow a natural organization *and* get the cyclic dependencies fixed. The project argouml-core-lib is an artificial project which was created solely to satisfy Eclipse requirements at the time. Its contents should be part of the main ArgoUML project. There are really only three "natural" ArgoUML plugins right now: 1) the main ArgoUML project, 2) argouml-core-model, and 3) argouml-core-model-mdr. > I find out there is one solution that solves all of these > problems: Eclipse buddies. It's a mechanism that forces the > ClassLoader from a plugin to find a class from a plugin that > it's in cyclic dependence with the first plugin. I observed > that this works for static blocks of code also. And (what got > me here in the first place) this forces ArgoEclipse to beahve well, :) I'm not sure I fully understand this. Is there someplace that describes Eclipse buddies in more detail? > I have write access to ArgoEclipse SVN repository and I can > just commit my work, how should I send you the code for > ArgoUML: patches, discuss the code on the maillist? The mailing list is good for general discussions, but patches attached to an issue in the bug database provide a more focused discussion among those interested. I think we need to make better use of the ArgoEclipse issue database, so perhaps this would be a good opportunity to start with. Tom > -----Original Message----- > From: Bogdan Ciprian Pistol [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 03, 2007 12:26 AM > To: Tom Morris; ArgoUML Developers > Subject: ArgoEclipse issues > > > Hello, > > ArgoEclipse doesn't work, > - it throws errors when the user is trying to open a zargo > file or create a new one with the new wizard. > - Log4j doesn't work. (log4j:WARN No appenders could be found > for logger <some class>. log4j:WARN Please initialize the > log4j system properly.) > - The model MDR implementation doesn't work the "ArgoUML > standard way", the client (eg ArgoEclipse) must instantiate > the MDRModelImplementation and then sets the Model to use the > MDR implementation. > - The static blocks of code from classes, that should run > when the class is initially accessed from argouml* doesn't work. > > Some causes of these problems are because: > > - some cyclic dependencies between argouml* projects in > Eclipse: (eg log4j, some GEF functions - > org.argouml.i18n.Translator.init() calls > Localizer.addResource("UMLMenu", > "org.argouml.i18n.UMLResourceBundle"); which throws > java.util.MissingResourceException) > - static blocks of code that don't run when the class that > contains them gets accessed > > Why does this happen? > > Eclipse uses a different ClassLoader for every plugin, so when a > argouml* project is running as a plugin and tries to find a > class the ClassLoader looks in his domain (the plugin itself) > and _only_ in other plugins declared in Manifest.MF (and the > plugins declared in Manifest.MF cannot depend on the first > plugin because it will be a cyclic dependence) > > I thought the only way to solve these problems is: > - do not split ArgoUML in projects argouml* in Eclipse (that are also > plugins) or > - remove all of these cyclic dependencies, and adjust the > static initialization blocks from classes (essentially copying them in > ArgoEclipse) > > It's desirable the second choice, but there are problems. > > I find out there is one solution that solves all of these > problems: Eclipse buddies. It's a mechanism that forces the > ClassLoader from a plugin to find a class from a plugin that > it's in cyclic dependence with the first plugin. I observed > that this works for static blocks of code also. And (what got > me here in the first place) this forces ArgoEclipse to beahve well, :) > > I have write access to ArgoEclipse SVN repository and I can > just commit my work, how should I send you the code for > ArgoUML: patches, discuss the code on the maillist? > > Bogdan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
