On Fri, May 7, 2010 at 4:55 AM, Thomas Neustupny <[email protected]> wrote:
> 1. Tagged values for UML2: [...] also we restrict TVs to strings (this > restriction also didn't exists for UML 1.4, btw.). This is unfinished work from the UML 1.3 to 1.4 transition many years ago. The relevant bug is http://argouml.tigris.org/issues/show_bug.cgi?id=4936 which includes a patch, but it needs work. Some of the AndroMDA profiles would benefit from support for Boolean, etc types, as I remember. > 2. Documentation tab for UML2: doc was stored as TV in the model for UML 1.x, > which is not allowed in UML2. Currently I think that comments are the only > way to store documentation in the model and make this tab functional again. > This would also imply that all the other ArgoUML specific tagged values (@author, @since, @version, @deprecated, etc) are going to get dropped. I haven't looked closely at the spec, but it seems like there should be a way to have an ArgoUML profile with any needed properties. > 4. UML2 load&save from/to XMI: importing XMI from other tools with eclipse > EMF often results in Ecore models instead of UML models, which makes them > unusable for ArgoUML. I think we configured the factories wrong in > EUMLModelImplementation, but I have no clue how to fix this. It bothers me, > because I'm interested in model interoperability, see the few sample models > here: http://www.omgwiki.org/model-interchange/doku.php (I'm in the mailing > list and have an actual internal compatibility matrix for the listed vendors, > if someone is interested.) > Is there a reason not to put the matrix on the wiki? As far as the OMG goes, I tried to get ArgoEclipse included over a year ago and did models which conformed to their original experiment. Kenn Hussey checked with the OMG who said it was restricted to members only. On Fri, May 7, 2010 at 7:28 AM, Bob Tarling <[email protected]> wrote: > I would like to start separating out the diagrams into separate > eclipse projects (within the main ArgoUML repository), restructure the > packages and encapsulate the Figs (ie they will no longer be public > scope). The problem is that is a major API change with no deprecation. Once the ArgoUML original design was done, allowing the implementation details to show through, the problem was inevitable. The only thing you can control now is timing. Given the magnitude of changes that will be required for UML 2.x, it seems like now is as good a time as any. It's pretty unlikely that binary compatibility is going to be preserved across the UML 1.4 to UML 2.x transition anyway. You might want to look at the interface that I introduced, org.argouml.uml.diagram.ui.ArgoFig, to see if that provides something that you could build on. Tom ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2605099 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
