Matthias,

There are aspects of this new decorator that make me uncomfortable.

My concerns come two basic areas:
1) Frozen Stream  - AndroMDA 2.0.X stream has been frozen
2) Decorator Model - the new decorator model is prototype quality work, not
production

Point (2) is also related to the upcoming  model transformation work.

Frozen Stream
-------------
The AndroMDA 2.0.X stream has been effectively frozen.  No new (backward
compatible) development can happen in that stream.  Therefore new cartridge
development has been effectively frozen.

For example, I have no interest in developing a cartridge for AndroMDA 3.x
until the AndroMDA core has stabilized.  But, I would on the other hand do
cartridge development on AndroMDA 2.x if I had a reasonably comfortable
feeling that the core was not going to change underneath me.

In that spirit I have been restricting all my new cartridge development to
2.x.  I would like to be able to offer that work to users at some point, but
I won't be able to offer it on the 3.x stream.

Decorator Model
---------------

I do not believe there is 'one' set of decorator objects that will work for
all cartridges. I don't even believe there is necessarily an N-to-M mapping
for the set of decorators for one cartridge to decorators in another
cartridge.

Therefore I am less than convinced that triggering on a meta-model object
creation event from the repository is the correct model for
creating/extending decorators. At the very least it has not been
demonstrated as a workable method in any cartridge prototypes.

The prototyping I have been doing on a XSD/WEB Services generating cartridge
has started me thinking that the solution probably looks more like a model
transformation solution than a decorator morphing/extending solution.  In my
prototype I transform a model in the UML (Universal Modelling Lanaguage) to
a model in a XSD modelling lanaguage.  I believe this is exacatly the model
refinement that Peter was talking about in an earlier e-mail.

I then use velocity templates to generate from my XSD model. The velocity
templates end up looking much simpler than our typical AndroMDA template.  I
also have the added benefit of ending up with a formal object model that
describes how my cartridge works.  This leads me to think we could actually
use AndroMDA to help author cartridges and to create cartridge specific
meta-languages. (See textbook: Executable UML by Marc Balcer ).

I believe the current EJB cartridge templates are so complicated because
they are trying to generate code from the wrong meta-model (UML meta-model
instead of a EJB meta-model).  The code in the velocity templates
essentially ends up trying to do the meta-model transformation on the fly in
order to get at the data it needs to generate code.

Regardless of which approach may or may not work, my point is that we have
yet to successfully prototype a convincing solution to the problem.
Therefore I think it is premature to ask anybody to redesign, or refactor
their cartridge templates.

Conclusion
----------

I would suggest we do the following:

Reopen the 2.X stream for backward compatable changes only. That would
include new cartridge development and backward compatable changes to the
core.  We continue to prototype the decorator model changes you have started
in the 3.X stream.  We port Wouter's and Richard's cartridge work back into
the 2.x stream. At some point, when the 3.X stream is stable, and the new
concepts have been proven for use in production we then port from 2.x to
3.x.

Otherwise we effectively have a dead 2.X stream and an unstable 3.X stream.

The reason I am suggesting this is because I would imagine I am not the only
person being affected by the changes in the 3.X stream. The current
situation is that I have to essentially ignore the 3.x stream if I want to
use AndroMDA for any reall production related activites.  On the other hand
I would like to leverage the work Richard and Wouter did on their EJB and
STRUTS4BPM cartridges.

Therefore I find myself having to decice between porting Richard and
Wouter's new cartridge, or ignoring their work.  Their work is not the only
work that will fall into that category.  There will soon be Matthew's MAVEN
work too.  Where should it go? 2.x or 3.x?

- Tony

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Matthias
> Bohlen
> Sent: Sunday, November 16, 2003 2:48 AM
> To: [EMAIL PROTECTED]; 'Anthony Mowers';
> [EMAIL PROTECTED]
> Subject: [Andromda-devel] Migration rules to metamodel decorators
>
>
> Hi Tony, Wouter and the others,
>
> would you please have a look at my migration table to metamodel
> decorators that I have checked in under the docs-work/ subdirectory in
> CVS? I have described there what will happen to all the methods in the
> dynamic proxies and the script helpers. As it looks today,
> SimpleOOScriptHelper will almost be deleted, only one method remains!
> :-)
>
> Please read the Excel file (or the HTML equivalent) and ask yourself:
> * Did Matthias create decorators for all metaclasses I need?
> * Will Matthias delete any methods I need?
> * Will he move all my methods to an appropriate place?
>
> The dynamic proxies (P*.java) and their interfaces (UML*.java) will all
> be deleted because they are now replaced by decorators that have all the
> methods in their source files. The decorators are documented in the UML
> model called ProfileForMetamodelDecorators.zuml that I also checked in
> today (some may still be missing, but you'll get the idea).
>
> For Wouter: I did not split UMLDynamicHelper into decorators, yet. Could
> you please think about which decorators you need and update
> ProfileForMetamodelDecorators.zuml and the migration table accordingly?
> I won't touch the model until you tell me that you're done.
>
> Thanks...
> Matthias
>
> ---
>
> Matthias Bohlen
> "Consulting that helps project teams to succeed..."
> http://www.mbohlen.de/
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=/g22lp.tmpl
> _______________________________________________
> Andromda-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/andromda-devel



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Andromda-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/andromda-devel

Reply via email to