Bob Fields wrote:AndroMDA definitely hasn't been abandoned, there's lots going on, and it still has the best UML to code implementation around. There's a few of the core developers left and the existing infrastructure, plus some new people (myself included).
That's good to hear. I haven't been following CVS recently, so I was mostly going by forum activity and the disappearance of folks like Chad, Wouter (and of course Matthias), but Ohloh, for what it's worth, also seems to think the project is abandoned. http://www.ohloh.net/p/AndroMDA
If that's just an issue with the CVS registrations there or something, it might be worth fixing them so folks don't get the wrong impression.
Bob Fields wrote:As long as the xmi:id remains the same, and the UML14 implementation is updated to check for the new format, everything should remain compatible in existing UML14 models.
Presumably the UML14 metafacade/cartridges would look for both the old and
the new names so that they'd continue to work with models which are still linked to the old profiles (as well as models which are linked to homebrew profiles or contain the necessary Stereotypes and TagDefinitions which were created by hand directly in the model).
Of course folks with homebrew profiles should follow the same strategy to migrate them forward, changing the names, but keeping the xmi.id values the same.
Bob Fields wrote:The profiles can be made UML tool agnostic even though they have the UML Standard Profile. MagicDraw adds the MagicDraw profile which can be removed separately or can be added as a separate dependency.
The issue isn't the UML Standard Profile (or any other linked profile), but rather the way MagicDraw serializes what they call "modules." If you look at the XMI for one of the modules, you'll see that it contains some outer packages which MagicDraw basically ignores when it reads things back in. The combination of those containing packages and the containing packages in the linked-from XMI create a situation where the profile package is trying to be in two places at once causing a composition violation if you try to read the linked XMIs with a conformant reader.
I don't know if they can read models which are serialized correctly. If they can't and you want to continue to use MagicDraw to maintain the profiles, then some type of post-processing is probably required.
The NetBeans MDR library is one conformant reader which can't read these profiles, but the AndroMDA developers side stepped the problem by hacking MDR to work around the problem (but didn't publish their diffs which I'm pretty sure is a violation of Sun's license).
If anyone is interested in more detail, you should be able to find past discussions either here in the forums or in the mailing list archives for the period before when a mailing list was used instead of a forum.