Hello Michiel!
You don't have to move the ArgoVersion class. You can let the
Application subsystem register the version with some low level subsystem
when it starts and then all other parts retrieve the version from there.
The question we should ask ourselves is what the version of the
application represents. If it represents the version of the application,
then it would be good to register it like this. As a consequence
ArgoEclipse would have its own version registered by its own application
subsystem (since it is another application). If it represents the
version of the code then it should be down there everywhere. In the
second case I think it is rather pointless because we have subversion
and our configuration management work to keep track of what version of
every file that goes into every distribution.
It looks like it is used for information (the splash), in projects and
then when saving the model. I suspect that when it is used in the
project and for saving the model it is more or less just information
since we also have a persistence version.
I would like to suggest that we register it somewhere where the splash,
the code generation and model saving can fetch the information, let test
cases register something appropriate for their test, and let ArgoEclipse
register its own version.
/Linus
> -----Original Message-----
> From: Michiel van der Wulp [mailto:[EMAIL PROTECTED]
> Sent: den 21 april 2007 19:02
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
