It sounds like we are in agreement. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Matthias > Bohlen > Sent: Monday, November 17, 2003 12:26 PM > To: 'Tony Mowers'; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [Andromda-devel] Stable and unstable versions > > > 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=/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
