I will now commit this change. It is not complete w.r.t. the test cases.
I have done the work in Eclipse and will commit to fix the tests in the
ant version. Until this is done, the tests will fail. I hope I am done
with fixing the tests tonight.
/Linus
> -----Original Message-----
> From: Tom Morris [mailto:[EMAIL PROTECTED]
> Sent: den 30 april 2007 22:48
> To: [email protected]
> Subject: RE: [argouml-dev] Detangling MDR from the model subsystem
>
> > I have a memory of someone thinking it would be a good idea not to
have
> the MDR instantiated by default from the Model subsystem.
>
> It creates a circular dependency between org.argouml.model and
> org.argouml.model.mdr (although the dependency is hidden from our
tools
> because the classname is encoded as a string). The application should
be
> responsible for wiring together the various components, they shouldn't
be
> doing it themselves.
>
> > I have identified the following changes:
> > * MDR to be instantiated in the application subsystem (probably
> org.argouml.application.Main) and fed to the Model subsystem.
>
> Yes, org.argouml.model.mdr.MDRModelImplementation should be an input
to
> org.argouml.model.Model, not something that it knows about internally.
>
> > * As a consequence of this, the ArgoEclipse application will also
have
> to
> instantiate it.
>
> That's not a problem.
>
> > * All test cases that actually use the model will have to
instantiate it
> (except those using the mock model).
>
> Isn't the mock model just another model subsystem implementation?
>
> Some tests cases don't work properly if there isn't a root model, so
it
> might be worth centralizing code to satisfy the minimum initialization
> requirements for the model subsystem someplace where all the tests can
use
> it.
>
> > * For extra credit, we could throw a special NotInitializedError ...
>
> This sounds like optimizing an error case. I think a
NullPointerException
> on the first access will make the problem pretty obvious without us
having
> to explicitly check whether we're initialized all the time.
>
> > Have I missed something important that will complicate this later?
Is
> this
> worth doing now?
>
> Bogdan's workaround took care of the immediate problem, but I think
it's
> worth fixing this.
>
> Not really related, but another issue with the model subsystem is that
it
> assumes there's only a single implementation loaded at a time. This
> requires an application restart to change model subsystems. It would
be
> useful to be able to choose the model subsystem to use on a
per-project
> basis and, in the future when we can have multiple projects open, to
be
> able
> to have them loaded simultaneously so that elements can be copied from
one
> model subsystem to another.
>
> Tom
>
> ---------------------------------------------------------------------
> 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]
