are you reverse engineering the UML form the code?
and .. what format(s) is your output likely to be?
I've recently discovered the excellent magic draw UML tool
http://www.magicdraw.com (java based so x-platform) which will reverse
engineer code sets into UML XML files and also output Rose-format project
files.
I'm planning to use it in our work here, because the vanilla XML (not
zipped) works a treat with cvs, and it seems to me that that would be a
major factor in an OS project.
Unfortunately I'm still using an evaluation licence, pitting it against Rose
and Together, and James is too big for the eval version.
However it takes less than five minutes to generate the *whole* UML from
code, *and* produce a class diagram of the whole shooting match (if your
classpath settings are straight, as always).
(just a thought)
d.
> -----Original Message-----
> From: Stanley,Michael P. [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 26, 2001 5:34 PM
> To: [EMAIL PROTECTED]
> Subject: MailetConfig
>
>
> I've been reading James code for the last several days (I've even begun
> drawing up some UML to help get better understanding of it). Just to
> begin I would like to say that this is a great project, and I am excited
> to offer my help. I will be putting in some time to help with this
> project.
>
> It seems that MailetConfig is implemented in the very core and has only
> one implementation 'INLINE'. This seems to be good for most mailets
> that are used, however I can forsee it leading to problems and I also
> think that this approach almost wastes the abstraction of having a
> MailetConfig interface. And the way it seems to be implemented is that
> you choose an implementation and it is for all mailets.
>
> Ok, to get to the point, I am suggestioning maybe there would be a way
> to allow each Mailet to choose how to implement its configuration.
> (i.e. INLINE, EXTERNAL (in a another file), JDBC, JOHNNY_X, etc). Why
> do I think this is important? Say you have a Mailet that gets repeated
> (i.e listserv) and its configuration starts getting long, this could
> potentially could make a config.xml file unreadable. Now if each
> listserv was able to point to an external file for its configuration
> this wouldn't be the case. There are two ways to approach this, the
> listserv could add a configuration child file that knows where to look
> or it can benefit from a more global abstraction where the deployer has
> the freedom to choose its configuration.
>
> Proposed possible approach.
>
> when I mailet is entered in config.xml it could look something like this
>
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager">
> <configFile>[EMAIL PROTECTED]</configFile>
> </mailet>
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager" config="INLINE">
> <membersPath> file://var/users/list-james </membersPath>
> </mailet
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager" config="EXTERNAL">
> <configFile>[EMAIL PROTECTED]</configFile>
> </mailet>
>
> This shows how the Default config is INLINE so this won't break existing
> structures.
>
> What are peoples thoughts on this? I would like to here some opinions
> before attempting patches.
>
> Mike
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
