Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [gmt-dev] Fw: [gme-users] Please Fix Versioning Hell!

Ed,
I think that you again prove my point, that the best way to use GMT is by
using only its XML output, or a wrapper that produces XMI in the right
format. Then, if GME changes, at best the wrapper needs change, not any
other components that use GME output.

This does not solve any internal GME paradigm problems as you describe. I
hope with you that the GME team will solve the problems. Does any of you
follow the gme-users discussion?

Regards,
Ghica van Emde Boas
Bronstee.com Software & Services b.v.
e-mail: emdeboas@xxxxxxxxxxxx,
tel: +31 23 5474422,
or: +31 6 53368747 (mobile)
fax: +31 23 5473347


> -----Original Message-----
> From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx]On
> Behalf Of Ed Willink
> Sent: Tuesday, June 01, 2004 9:39 PM
> To: gmt-dev@xxxxxxxxxxx
> Subject: RE: [gmt-dev] Fw: [gme-users] Please Fix Versioning Hell!
>
>
> Hi Ghica, Jorn
>
> I endorse the problems fully but not the diagnosis.
>
> [The UMLX distribution within GMT is now almost unuseable since
> it provides two GME3 DLLs, and if you use a current GME4 download
> one out of two is incompatible.]
>
> I think it is much more to do with necessary/careless COM usage.
> The same should be much more avoidable within Eclipse where
> each plug-in can have its own class-path. There certainly should
> be no shared set of registry settings.
>
> The problems with GME are actually worse than outlined.
>
> The GME installation follows Microsoft 'trash the previous
> release' policy with enthusiasm. If you upgrade GME, you must first
> use the old GME to export all old designs to XML, then upgrade,
> then import the old designs. Of course if you forget one, or get one
> from a third party (the UMLX distribution) you have to uninstall
> GME4, reinstall GME3, rescue the old design, then install all
> over again. (If you're lucky you may get away with the wrong version.)
>
> ==> GME is not fit-for-purpose with respect to GME release upgrades.
>
> Worse, if you use GME libraries, you are in even greater trouble,
> since just upgrading the paradigm on something in a library changes
> the 'id's and so the references to the library are trashed. I had
> to re-instantiate my UMLX designs after some upgrades.
>
> ==> GME is not fit-for-purpose with respect to GME paradigm upgrades.
>
> And if of course you try to use libraries, you soon discover
> that they're not transitive: libraries cannot reference other libraries.
>
> ==> GME is not fit-for-purpose with respect to libraries.
>
> I'm sorry to be so negative about GME, which is otherwise a very
> useful powerful tool. It's just very difficult to expand the usage
> of GME reliably from what works for me today, to what will work
> predictably for anyone else anywhere else anytime else.
>
> I hope that these problems will vanish in the planned rewrite.
>
> 	Regards
>
> 		Ed Willink
>
> -----Original Message-----
> From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx] On
> Behalf Of Ghica van Emde Boas
> Sent: 01 June 2004 16:15
> To: gmt-dev@xxxxxxxxxxx
> Subject: RE: [gmt-dev] Fw: [gme-users] Please Fix Versioning Hell!
>
>
> This is indeed an interesting horror story. It is also extra reason to
> stick to a common intermediate format, such a Ecore and XMI. In that
> case there will always be just one point of change.
>
> Regards,
> Ghica van Emde Boas
> Bronstee.com Software & Services b.v.
> e-mail: emdeboas@xxxxxxxxxxxx,
> tel: +31 23 5474422,
> or: +31 6 53368747 (mobile)
> fax: +31 23 5473347
>
>
> > -----Original Message-----
> > From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx]On
> > Behalf Of Jorn Bettin
> > Sent: Monday, May 31, 2004 12:22 AM
> > To: gmt-dev@xxxxxxxxxxx
> > Subject: [gmt-dev] Fw: [gme-users] Please Fix Versioning Hell!
> >
> >
> > Thought it worthwhile to cross-copy us on this post, see below.
> >
> > 1. We should bear the GME versioning approach/issues in mind when
> > integrating GME with GMT 2. Some important lessons for the development
>
> > of GMT. GMT's role of an MDA tool orchestration component means that
> > we can't afford any of the versioning issues illustrated below.
> >
> > Jorn
> >
> > Jorn Bettin
> > jorn.bettin@xxxxxxxxxxxxxxxx
> > www.softmetaware.com
> > Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534
> >
> > ----- Original Message -----
> > From: "Gabriele Trombetti" <gabtromb@xxxxxxxxxxxxxxxxxxx>
> > To: "gme-users" <gme-users@xxxxxxxxxxxxxxxxxxxxxxxx>;
> > <udm-users-request@xxxxxxxxxxxxxxxxxxxxxxxx>; "GReAT-users"
> > <great-users@xxxxxxxxxxxxxxxxxxxxxxxx>
> > Sent: Sunday, May 30, 2004 10:33 AM
> > Subject: [gme-users] Please Fix Versioning Hell!
> >
> >
> > > With the following story, I'm trying to pushing for efforts to be
> > > made to reach an agreement which could allow various versions of
> > > GME, UDM, GReAT, OTIF interoperate.
> > >
> > > -------
> > >
> > > I'm working on a conversion between PICML (a GME project made here
> > > in
> > > Vanderbilt) format to an XML format that reflects Cadena
> > > (http://cadena.projects.cis.ksu.edu/) project structure and vice
> versa.
> > >
> > > I'm working with GReAT for this conversion, and the resulting XML is
>
> > > to be published on the OTIF backplane.
> > >
> > > My work has become _incredibly_ difficult lately, because of the
> > > interface versioning problems of GME (primarily) and UDM, GReAT,
> > > OTIF.
> > >
> > > In the beginning we (PICML developers) were using GME3.10.13 . At
> > > first my conversion project was not feasible because the GReAT 1.2.3
>
> > > was using an UDM version which did not allow me to create subtypes
> > > and instances of a model, and this was absolutely a requirement for
> > > PICML.
> > >
> > > The newer version of UDM (2.14.2 unofficial) could do that. With
> > > almost every other development tool I know, this would just mean
> > > overwriting the current UDM with the new UDM 2.14.2 and going ahead.
>
> > > But instead this new UDM would not work with GReAT 1.2.3 nor GME3.
> > > So I had to ask Adi to build an unofficial version of GReAT with UDM
>
> > > 2.14.2 for me. At that point it worked, but that version was running
>
> > > for the latest released GME which was GME4.3.17 .
> > >
> > > So I had to detach from the other PICML developers which were still
> > > working with GME3, and migrate my copy of PICML metamodel to
> > > GME4.3.17 (also in the repository now we have 2 versions: the
> > > official one, and
> > mine)
> > >
> > > Our clients (sponsors) also had problems because in order to use my
> > > transformation they had to uninstall GME3 (and possibly UDM),
> > > install GME4.3.17, install GReAT and UDM and perform the
> > > transformation.... And then go back uninstalling everything and
> > > reinstalling GME3 which was the platform of choice for working with
> > > PICML. A bit a tedious job for just performing an export of their
> > > model to Cadena!
> > >
> > > Then additional problems came:
> > > For my project I need to publish the xml file (output of GReAT) onto
>
> > > the OTIF backplane. A version of OTIF for GME4 doesn't exist yet.
> > > Zsolt built an unofficial one for me, but that one was using the
> > > latest UDM which is 2.16 and only works with GME4.5.18, while the
> > > latest version of GReAT (which is mine) works only with UDM 2.14.2
> > > and GME 4.3.17 .
> > >
> > > So I still could not use OTIF and GReAT together; and to swap from
> > > one to the other required some 30 minutes of uninstalling and
> > > reinstalling the whole world.
> > >
> > > Then Kitty found that there were a few serious bugs with the code
> > > generation in all the available versions of UDM, which would make
> > > all the C++ generated code impossible to compile for PICML. This
> > > also affected ME but I hadn't tried to compile the GReAT generated
> > > code until then.
> > >
> > > The fixes in UDM have been promptly made by Zsolt, but now we have
> > > to upgrade! Oh Zeus, what will happen now? We will have to ask the
> > > GReAT team to make a new release of GReAT with this new UDM, and the
>
> > > OTIF team also! The GReAT and OTIF teams in general are not always
> > > in sync and ready to make a release for every version of UDM and
> > > GReAT that comes out, anytime! They might have big changes ongoing,
> > > which means that their code might not even compile at that time.
> > >
> > > Now we have 3 softwares: UDM, GReAT, OTIF; and as soon as we find a
> > > show-stopper bug in one of them we have to ask to THREE teams to
> > > rebuild their software before we can go ahead with our project!
> > >
> > > And most of those versions I have written about have not been
> > > officially released, which means that our sponsors currently are not
>
> > > even able to access our work! What do we tell them?
> > >
> > > I have never seen such a versioning hell happening before. I'm not
> > > sure where it comes from, but sure it has to be fixed as soon as
> > > possible.
> > >
> > > I suspect it starts from GME and it's COM interfaces. Well, wherever
>
> > > you read about COM, you will read that COM was made in such a way to
>
> > > REDUCE the versioning problems, not to increase them.
> > >
> > > AFAIK with COM it is possible to inherit the interfaces, like in
> > > CORBA, right? Then please GME folks, keep the old interfaces
> > > available and make the variations on new derived interfaces. Who
> > > cares if you need to increase the GME size by 200K every new version
>
> > > because you are keeping the old interfaces and a part of the old
> > > code for backward compatibility, this is *normal* when making
> > > software.
> > >
> > > At least you have to maintain compatibility within the same major
> > > version number; this is what the major version number is for, isn't
> > > it?
> > >
> > > Then I don't know what other fixes are needed but I suggest that the
>
> > > 4 leading teams (GME, UDM, OTIF and GReAT) should meet together
> > > *soon* to start ensuring inter-version compatibility.
> > >
> > >
> > > Thank you
> > > Gabriele Trombetti _______________________________________________
> > > gme-users mailing list
> > > gme-users@xxxxxxxxxxxxxxxxxxxxxxxx
> > > http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
> > >
> >
> >
> > _______________________________________________
> > gmt-dev mailing list
> > gmt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/gmt-dev
> >
> > --
> > This message has been scanned for viruses and dangerous content by
> > MoveNext MailScanner, and is believed to be clean.
> >
> >
>
>
> _______________________________________________
> gmt-dev mailing list
> gmt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/gmt-dev
>
> --
> This email has been verified as Virus free
> Virus Protection and more available at http://www.plus.net
>
>
> _______________________________________________
> gmt-dev mailing list
> gmt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/gmt-dev
>
> --
> This message has been scanned for viruses and dangerous content
> by MoveNext MailScanner, and is believed to be clean.
>
>




Back to the top