I've been working with AndroMDA for about a year and, while I sympathise with the dire experiences recounted above, my reaction is, "But that isn't the case with AndroMDA!"
If your development team has already gone down the widely accepted route of -- Eclipse / Ant / xDoclet / Subversion / Spring / Hibernate / Tiles / Struts / jBoss -- you would be crazy not to give AndroMDA a chance. It permits you to continue doing exactly what you do now, but takes over the donkey work. If Maven is like Ant on steroids; AndroMDA is like xDoclet on steroids.
This SlashDot topic was sent to me by a colleague worried about my push for MDA where we work. Rather than comment privately just to him, I thought I'd make my views public. I hope you find the following helpful...
... , but overall, I still prefer the safety net of being in control of the coding process, and actually understanding what is going on under the hood.
I've had the same experience in the past with products that make all the easy bits easier -- and the hard bits impossible.
AndroMDA generates established best-practice Java patterns in a clear and concise structure. All the generated code is visible and available for editing (I refresh my Eclipse project and see all changes). Code that you need to alter is kept in separate directories and written there once. On the rare occasions in which you need to substitute 'unalterable' generated code with something special, you specify a substitution directory that precedes the targets directory in the build path. Due to the very consistent and sensible pattern adherence, there are a lot of very small java files. When you do need to substitute, the likelihood of your substitution AND the original both needing edits is low.
My experience is that I am completely in control of the coding process. A key thing about AndroMDA is that it actually tries to do very little . The yet-to-be-generated code resides in Velocity templates. AndroMDA loads UML into an object map (metafacade) that Velocity scripts traverse while filling in template fields as they go. Those many Velocity scripts are orchestrated with Maven. By leveraging so many best-in-class OSS projects the AndroMDA team keeps its own efforts very tightly focussed.
I have only looked briefly at xDoclet, but if you are concerned about "being in control of the coding process" AndroMDA is scarcely more invasive than xDoclet.
Then you are at square one, writing a custom MDA that works for you. ... and... Near the start of the project, the company had hired an MDA guru, who designed the MDA and, I belive implemented most of its core. Over time the MDA core portion expended in into a massive code generator that took hours to run and required tons and tons of memory.
That is about as necessary and sensible as creating your own http server. If you have someone breathing down your neck for results, don't even think about creating your own MDA. If you have that much time on your hands &/or a special need, create a new cartridge for AndroMDA that takes over where its existing cartridges leave off.
Seems to me that the amount of knowledge of the tools required for these code generators closely matches the amount of knowledge of a language required to create a decent app.
In the case of AndroMDA that's about right. However, developing an n-tier J2EE &/or.NET corporate architecture goes immensely beyond that. There is an AndroMDA.NET suite underway. AFAIK, at this time it is not possible, but in the mid-term you will be able to generate a J2EE and a.NET system simultaneously from a single UML model. This is incredible leverage of the "amount of knowledge of a language required to create a decent app"
Slashdot Mirror
I've been working with AndroMDA for about a year and, while I sympathise with the dire experiences recounted above, my reaction is, "But that isn't the case with AndroMDA!"
...
... , but overall, I still prefer the safety net of being in control of the coding process, and actually understanding what is going on under the hood.
... and ...
.NET corporate architecture goes immensely beyond that. There is an AndroMDA .NET suite underway. AFAIK, at this time it is not possible, but in the mid-term you will be able to generate a J2EE and a .NET system simultaneously from a single UML model. This is incredible leverage of the "amount of knowledge of a language required to create a decent app"
If your development team has already gone down the widely accepted route of -- Eclipse / Ant / xDoclet / Subversion / Spring / Hibernate / Tiles / Struts / jBoss -- you would be crazy not to give AndroMDA a chance. It permits you to continue doing exactly what you do now, but takes over the donkey work. If Maven is like Ant on steroids; AndroMDA is like xDoclet on steroids.
This SlashDot topic was sent to me by a colleague worried about my push for MDA where we work. Rather than comment privately just to him, I thought I'd make my views public. I hope you find the following helpful
I've had the same experience in the past with products that make all the easy bits easier -- and the hard bits impossible.
AndroMDA generates established best-practice Java patterns in a clear and concise structure. All the generated code is visible and available for editing (I refresh my Eclipse project and see all changes). Code that you need to alter is kept in separate directories and written there once. On the rare occasions in which you need to substitute 'unalterable' generated code with something special, you specify a substitution directory that precedes the targets directory in the build path. Due to the very consistent and sensible pattern adherence, there are a lot of very small java files. When you do need to substitute, the likelihood of your substitution AND the original both needing edits is low.
My experience is that I am completely in control of the coding process. A key thing about AndroMDA is that it actually tries to do very little . The yet-to-be-generated code resides in Velocity templates. AndroMDA loads UML into an object map (metafacade) that Velocity scripts traverse while filling in template fields as they go. Those many Velocity scripts are orchestrated with Maven. By leveraging so many best-in-class OSS projects the AndroMDA team keeps its own efforts very tightly focussed.
I have only looked briefly at xDoclet, but if you are concerned about "being in control of the coding process" AndroMDA is scarcely more invasive than xDoclet.
Then you are at square one, writing a custom MDA that works for you.
Near the start of the project, the company had hired an MDA guru, who designed the MDA and, I belive implemented most of its core. Over time the MDA core portion expended in into a massive code generator that took hours to run and required tons and tons of memory.
That is about as necessary and sensible as creating your own http server. If you have someone breathing down your neck for results, don't even think about creating your own MDA. If you have that much time on your hands &/or a special need, create a new cartridge for AndroMDA that takes over where its existing cartridges leave off.
Seems to me that the amount of knowledge of the tools required for these code generators closely matches the amount of knowledge of a language required to create a decent app.
In the case of AndroMDA that's about right. However, developing an n-tier J2EE &/or
My J2EE development experience ended more or less