What would it take to update MDR to the correct versions of MOF and XMI?
Is there another open source MOF/CWM tool out there with a better
roadmap for this?
/Linus
> -----Original Message-----
> From: Tom Morris [mailto:[EMAIL PROTECTED]
> Sent: den 20 september 2006 08:56
> To: [email protected]
> Subject: RE: [argouml-dev] Keeping zargo file compatible with previous
> versions of ArgoUML
>
> I absolutely agree that we need to get out of the XML parsing business
as
> soon as humanly possible, but NetBeans MDR, as it stands today, isn't
> going
> to provide us with a path to UML 2.x Diagram Interchange. It doesn't
> support the prerequisite versions of MOF and XMI.
>
> Tom
>
> > -----Original Message-----
> > From: Linus Tolke [mailto:[EMAIL PROTECTED]
> > Sent: Monday, September 18, 2006 3:20 AM
> > To: [email protected]
> > Subject: RE: [argouml-dev] Keeping zargo file compatible with
> > previous versions of ArgoUML
> >
> >
> > Hello Bob!
> >
> > I would prefer that we do not have to write and maintain a
> > diagraminterchange.tee script and a Parser for this. We have
> > had problems with this as long as I remember (and we still
> > do). I am not sure of the details of the problems but my
> > guess is that they come from inconsistencies between the tee
> > script and the Parser.
> >
> > If we were to go for a solution where the XML-generator and
> > XML-parser are generated by MDR from a model, then there
> > would no longer be any inconsistencies.
> >
> > What we need is
> > - the model - it can be easily drawn from the Diagram
> > Interchange 2.0 specification, and converted to MOF.
> > - a glue between GEF and the MDR-generated code that together
> > with information from the UML model present an editable
> > diagram from the information in MDR. This would then be the
> > code of the Diagram Subsystem.
> >
> > If you say "We will write diagraminterchange.tee and a new
> > parser." I am thinking years of bugfixing and never getting
> > it quite right.
> >
> > /Linus
> >
> > > -----Original Message-----
> > > From: Bob Tarling [mailto:[EMAIL PROTECTED]
> > > Sent: den 17 september 2006 21:05
> > > To: [email protected]
> > > Subject: Re: [argouml-dev] Keeping zargo file compatible
> > with previous
> > > versions of ArgoUML
> > >
> > > GEF is not aware of MDR and there are no plans that it should be.
> > >
> > > GEF is a graph modelling system but it is the responsibility of
the
> > > application to save and restore those models in whatever format is
> > > required for that application.
> > >
> > > For ArgoUML that is the diagram interchange format. GEF does not
> > > prevent this work being done in ArgoUML.
> > >
> > > We can write diagram interchange in a simlar way as we do
> > for pgml by
> > > writing a diagraminterchange.tee script (or use some more standard
> > > template library such as velocity, freemarker or jamon). We
> > will have
> > > to write a parser similar to PGMLStackParser to read the data
back.
> > >
> > > This would not effect any subsystem dependencies.
> > >
> > > Bob.
> > >
> > > On 9/13/06, Linus Tolke <[EMAIL PROTECTED]> wrote:
> > > > Replying to an old mail...
> > > >
> > > > A stable and formal API and persistence format sounds very good.
> > > >
> > > > On the other hand, I agree with whoever mentioned it (Tom I
think)
> > that
> > > > we are approaching the point where the next change to the save
> > format
> > > > concerning the save format of diagrams should be a move to the
UML
> > 2.0
> > > > Diagram Interchange format.
> > > >
> > > > With risk of restarting the very confusing discussion from last
> > > > summer...
> > > >
> > > > If we go for UML 2.0 Diagram Interchange format then it should
not
> > be
> > > > very far fetched to put the diagram information in MDR
> > and have it
> > > > parameterized by a Diagram Interchange meta-model. If that is
the
> > case,
> > > > two groups of questions arise:
> > > >
> > > > Is GEF ready for this? Can GEF work while having things
> > like list of
> > > > figures, color, size, position, and sub-parts accessed from a
> > > > repository? Can GEF accept events with changes of things in the
> > > > repository? Can GEF work with sizes and positions in floats?
> > > >
> > > > How does this affect the relationship between the involved
> > subsystems in
> > > > ArgoUML: Model, Model MDR implementation, Diagrams, and
> > Persistence?
> > > >
> > > > Both these questions are for you, Bob, to answer. A clear "Yes"
on
> > the
> > > > first group of questions is required, otherwise I'd say,
> > GEF is not
> > > > ready for this.
> > > >
> > > > /Linus
> > > >
> > > > > -----Original Message-----
> > > > > From: Bob Tarling [mailto:[EMAIL PROTECTED]
> > > > > Sent: den 2 september 2006 15:28
> > > > > To: [email protected]
> > > > > Subject: [argouml-dev] Keeping zargo file compatible
> > with previous
> > > > > versions of ArgoUML
> > > > >
> > > > > There are various reasons why it is not possible to load a
zargo
> > file
> > > > > from a current release in a previous version of ArgoUML.
> > > > >
> > > > > I think there are 2 major problems that cause regular change.
> > > > >
> > > > > 1. Fixing errors in save due to previous ArgoUML bugs
> > > > >
> > > > > Some of these fixes must not be repeated. By saving a
> > persistance
> > > > > version we ensure that a fix is run once and only once when we
> > know
> > > > > that it is required.
> > > > >
> > > > > 2. Use of PGML and reflection to save and load diagrams
> > > > >
> > > > > The current method of saving diagrams as PGML means
> > every time we
> > > > > adjust the composite make up of a Fig then persistence format
> > differs.
> > > > >
> > > > > The problem comes if we have introduced some new Fig or
> > refactored
> > the
> > > > > name or package of an existing Fig. For the current ArgoUML to
> > read
> > > > > previous projects we have no problem as the upgrade XSL
adjusts
> > the
> > > > > project for these changes.
> > > > >
> > > > > However when a previous version of ArgoUML is used to
> > load such a
> > > > > project it will attempt to create each Fig by
> > reflection using the
> > > > > class names stored in the PGML. Obviously it won't find
> > these and
> > > > > BANG.
> > > > >
> > > > > In the past this tended to mean some random exception being
> > presented
> > > > > to the user, the user creates issues in the database
> > which we have
> > to
> > > > > investigate and our reply was always upgrade to latest
version.
> > > > >
> > > > > This is why I introduced the persistence version. A value that
> > > > > increments each time such a change has taken place.
> > Instead of an
> > > > > exception the user now sees a message asking them to upgrade.
> > > > >
> > > > > I hadn't previously seen this as a problem because ArgoUML is
> > becoming
> > > > > more stable and we want to push users towards that more stable
> > > > > release. I've tried to make changes as gradual as
> > possible saving
> > any
> > > > > more major changes until after a stable release of ArgoUML.
> > > > >
> > > > > Changes to the Fig structure are certainly likely.
> > Issue 3238 and
> > > > > issue 4426 spring to mind immeditely.
> > > > >
> > > > > We have problems now though of requirements of
> > > > > http://argoeclipse.tigris.org
> > > > >
> > > > > The argoeclipse project is not planning to keep step
> > with ArgoUML
> > > > > releases. They are keeping to their own schedule. This
> > means that
> > the
> > > > > latest version of argoeclipse may not be able to read a
> > save file
> > from
> > > > > the latest version of ArgoUML.
> > > > >
> > > > > The only solution I see is to move to a more formal fixed
format
> > than
> > > > > PGML for which we need to make a reader and writer that will
be
> > > > > modified for each version. The logical choice with be the OMG
> > diagram
> > > > > interchange format but I was hoping not to do such major
change
> > for a
> > > > > long time.
> > > > >
> > > > > With all of the above commments I'm not so sure if it's worth
> > spending
> > > > > time on issue 4431. This will not solve the requirements of
> > > > > argoeclipse as they will have compatability problems anyway.
> > > > >
> > > > > But it seems we have a catch 22. The requirements is to
> > stabalise
> > the
> > > > > persistence format but in order to do that we need to
> > change the
> > > > > persistence format.
> > > > >
> > > > > How do we go about this?
> > > > >
> > > > > As a slight aside. There has been some talk a couple of months
> > back
> > > > > about moving to ArgoUML 1.0.
> > > > >
> > > > > To my mind the most important thing for that release is not
the
> > bug
> > > > > count but a stable and formal API and persistence
> > format. I think
> > we
> > > > > have some way to go for that. Is that what we should be
> > concentrating
> > > > > on now?
> > > > >
> > > > > Bob.
>
> ---------------------------------------------------------------------
> 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]
