I think that the the classloader problem, while perhaps tricky, is definitely solvable.
I don't think Bob's workaround is necessary, but as a general comment on the topic he raised: > It seems that you can call the constructors of your own Figs > but creating by reflection has problems. > > So what I can do is provide an API in GEF where an > application can register a factory object to create diagrams. I think moving away from using reflection is a good idea. Having the diagram parser depend on an implied interface based on our internal class structure has proven to be quite fragile and I think a more formal interface is needed. Using reflection removes that formality. For something like a file format, having a stable, formally reviewed, slowly changing (or non-changing) interface is a good thing. Having said that if we're going to support pluggable diagram types, I think we should think through how this is done. What happens if I send my project to someone that doesn't have the module installed? Can they see the shape of the diagram, but not act on it? Does the whole project fail to load? How are they informed what module they need and where they get it? Personally, I think they should be able to see and print the diagram even if they don't have the module installed. Also, since GEF is nominally separate from ArgoUML, we shouldn't be directly exposing any of its internal APIs since this makes it impossible to change/replace in the future. (cf LeakyAbstraction) Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
