Hi Tony, thanks for your email. Let me clarify a few points (see below).
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Tony Mowers > Sent: Monday, November 17, 2003 7:43 PM > To: Matthias Bohlen; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Andromda-devel] Migration rules to metamodel decorators > > > 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. No, absolutely not! AndroMDA 2.0.x is just the last stable release but can still be enhanced and released quite often until AndroMDA 3.x has stabilized. However, changes for 2.x MUST be backward compatible. > 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. I do not plan to spend any major development efforts on the AndroMDA 2.x core any more because I consider that one as "in production". So, you can be sure that the core will retain the same API as before. > 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. Right. Cartridges that are considered "production quality" should be published on the 2.x stream, not on the 3.x stream until that one is stable again. By the way, this applies to the Hibernate 2 cartridge on 3.x as well. I already have considered to backport that to 2.x in order to release it soon! > Decorator Model > --------------- > I do not believe there is 'one' set of decorator objects that > will work for all cartridges. I do neither. > 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. Right. This is why I designed the concept of a "context" into the decorator factory. Each cartridge can register its own set of decorators inside its own context. The core will set the context in the decorator factory each time before it calls processModelElement() on a cartridge. So, the decorators will always be just what the particular cartridge needs. > 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. I'll prototype it on the Hibernate cartridge and on the EJB cartridge to show that it works with cartridge-specific decorators. > 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. In the future, the decorators will be instantiated on the PSM instead of the PIM. And sure enough, the decorators will be generated from a UML profile that can be exactly the formal object model that describes how your cartridge works. I have prototyped that on a UML profile for the EJB cartridge. It looks absolutely clear, simple and beautiful. > 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 ). Cool! This is exactly where I was heading! David Frankel described it in his MDA book, too (see chapter 6, "Extending and Creating Modeling Languages"). The remarks from the ArcStyler people (Axel Uhl) about AndroMDA and its mainitenance problems triggered this approach in me. > 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. Absolutely. This is why I want to understand Pieter's ideas as soon as possible and make model transformations possible. > 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. Yep. People should only give some feedback whether they think I have put enough into my migration table so that we will be able to replace the currently somewhat clumsy proxies and lengthy script helpers. Later on, the decorators can be re-generated to work on the PSM. This will take some time, though, so that I'd like to show them on the PIM as a proof of concept. I am sure that the templates will become simpler and easier to read. > > Conclusion > ---------- > > I would suggest we do the following: > > Reopen the 2.X stream for backward compatable changes only. No problem. It was never closed. > That would include new cartridge development and backward > compatable changes to the core. Sure. > We continue to prototype the > decorator model changes you have started in the 3.X stream. Right. 3.x is the right place to do that. > We port Wouter's and Richard's cartridge work back into the > 2.x stream. Wouter's is OK, Richard's is not backward compatible to the old EJB cartridge, though. > 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. OK. > Otherwise we effectively have a dead 2.X stream and an > unstable 3.X stream. The 3.x is unstable, agreed. 2.x, however, is still alive from my point of view. > 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. Let's port bpm4struts back as soon as Wouter and I have settled on the question about whether to generate form fields. Let's discuss again about porting back the EJB. > 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? It depends on the risk. If it is virtually risk-free, it can go to 2.x, if not, it should go to 3.x to become backported to 2.x. > > - Tony Cheers... 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=mm/g22lp.tmpl _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
