RE: [gmt-dev] standards for dependency management in the GMT code base

["Ghica van Emde Boas" <emdeboas@xxxxxxxxxxxx>]

Hi all,
Jorn, you can write faster than I can read! If this has to be a public
discussion, here goes.

First of all, if this has to be THE standard for GMT dependency management,
then it has to be placed on www.eclipse.org/gmt, or possibly on
www.mdsd.info, but not exclusively on the SoftMetaWare site.

Second of all, if this has to be a standard for our contributors to adhere
to, it should be readable by us as a standalone document. Well, of course,
we assume general litteracy on the subject of MDA and related concepts :-)
This does not include KobrA or Product Line Engineering or Bertrand Meyers
book. So, what are: commands, basic queries, derived queries and objects in
the context of component specification? I truly do not know and this is
important. I was almost fired once because of a discussion about "view"s,
where my view was a database view and my opponents view was an MVC view.

Third question, what should the component specification look like in
practice for example for Fuut-je, and more important, for applications being
developed with Fuut-je. There is never a 1-1 relationship between model item
and implemented item. The interfaces for the implementation are generated
and not specified. This would mean that the model, together with the
generation rules are the specification (this is of course very true). This
also means that we should find a way to generate the interface specification
in a way that is consistent with your standard (extra work, extra templates)
or find a better way to externalize the rules than looking at a template
implementation.

My reaction to examples containing Foo and Bar is always that this theory
could not be rooted in practice, and that I would start trying to understand
it if it is changed to a nuts and bolts, order and products, or a students
and courses example. My reaction to "cool stuff" is similar. I do not think
we want to associate ourselves with a nerdy environment. Please make a real
example out of it!

I have also a serious question. Assume that we are going to use Apache, or
worse, Shark, as an open source component. Is it then our responsibility to
externalize a component specification in our standardized way for this piece
of open source software? I think not. We can also not ask the authors of the
open source software to do that. It may be a very considerable piece of work
though and an essential piece in the externalized component specification.
Is this a stumbling block for using open source software? Actually I think
it is. Any thoughts?

Anyway, good start! Needs work.

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, June 21, 2004 3:25 AM
> To: gmt-dev@xxxxxxxxxxx
> Subject: [gmt-dev] standards for dependency management in the GMT code
> base
>
>
> Now, where Fuut-je is being refactored, and where we're embarking
> on further
> work, is a good time to roll out some sensible standards for dependency
> management in the GMT code base. The principles that I suggest we
> adhere to
> are described  in
> http://www.softmetaware.com/complexity-and-dependency-management.pdf, and
> they will allow GMT to become a true tool component "platform" - very much
> consistent with the spirit of Eclipse as a "platform". The document can be
> read as a recipie for avoiding the types of maintenance/versioning issues
> that were recently discussed on the GME mailing list, and similar issues
> that I've seen in many projects.
>
> Jorn
>
> Jorn Bettin
> jorn.bettin@xxxxxxxxxxxxxxxx
> www.softmetaware.com
> Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534
>
>
> _______________________________________________
> 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.
>
>