RE: [argouml-dev] PluggableImport API changes

Linus wrote:

> I would like for us to take this opportunity with the new 
> classes for the "import"-function, to create the interface 
> classes (ImportManager, ImportInterface, and ImportSettings) 
> in a package that is one level shorter. Either 
> org.argouml.reveng, org.argouml.import, or something else. An 
> update of section 5.7 in the Cookbook is then needed because 
> this new package will be the main package for the import function.

While I don't object to saving four characters in the package name, I do
think we should keep the code generation and reverse engineering side of
things parallel to each other to make it easier for folks to find stuff.  We
currently have GeneratorManager et al in org.argouml.uml.generator.  Since
it's presumably too late to change the API for code generation, I suspect we
should leave reverse engineering where it is as well.

BTW, I don't think the cookbook is accurate for the code generation side of
things (Section 5.8).

> The configuration panels and layout engines, if eventually 
> added again, should probably be provided by the GUI-subsystem 
> and not by the Reverse Engineering subsystem.

I think import modules need to be able to specify additional settings in a
GUI independent way.  A simple interface which specifies the type of setting
(boolean, string, etc) and labels for the setting and options (if
applicable) should be adequate for the vast majority of cases.

Pluggable layout engines I agree should not be part of reverse engineering.
I would have thought they'd extend the Diagram subsystem, but I'm not 100%
sure of the relationship between GUI and Diagram.

> I think the classfile module has some settings. Perhaps they 
> are exactly the same as the Java import.

Yes, they are the same.  As a matter of fact, most importers implement the
same two settings because a) the default implementation provides them and b)
the Modeller requires them.

Tom