Bugs: Browse | Download .csv
I have added the following : - inner classes/interfaces where handled correct - Enums - basic support for Generics - linking of other models to resolve the types - Handling of Annotations, they are Interfaces with a prefix '@' I'm not sure how to handle them, there a more like Stereotypes. I will think about it, maybe you have also suggestions. I also add a simple test project. greetings, urs.
Date: 2009-03-10 10:23 Sender: Thibault Landré Hi Urs, thanks for your new patch :) I have opened a new bug for your patch (because this one is fixed since the 2.1 version) : http://gforge.enseeiht.fr/tracker/?func=detail&atid=109&a id=2393&group_id=52 Best Regards, Thibault
Date: 2009-03-06 18:55 Sender: urs zeidler This is the patch fixing qualified Java name issue. Sorry for the long delay, it introduce also the abstract and static flag for some elements, the interface visibility, and can reconize String,Int and bool, default values. This patch only affects AbstractJava2UMLConverter.java.
Date: 2008-09-14 16:29 Sender: urs zeidler I think it's an error I introduced, so I will correct it. I have notice this behavior also, after working on a bigger project. Some additional : - the Abstract flag is not recognized, at least for Classes, I have to check this for methods - the visibility of features in an interface if not set (it is default) is the visibility of the interface, from what the java spec. states. - in the annotation import it is necessary to map the property types to the uml primitive type, so Class would match to String.
Date: 2008-09-14 00:02 Sender: Rafael Chaves Thanks for contributing this feature, Urs. Re: annotations - they map naturally to stereotypes indeed... Note sure if this patch is at fault, or if this was the behavior before, but I noticed that the tool gets confused if Java class references are fully qualified - it cannot resolve those, and ends up creating bogus data types with the names it cannot resolve (in this case, the data type element will have as the element name the fully qualified Java name.
Date: 2008-08-28 16:00 Sender: Thibault Landré Your patch have been comitted and will be available on the next release 2.1 Thanks for your efforts and reactivity :) Regards, Thibault
Date: 2008-08-27 23:20 Sender: urs zeidler Here a new patch with a correct header, and javadocs.
Date: 2008-08-01 15:26 Sender: raphaël Faudou Hi urs, Good job. we are going to try it and see if it is possible to package it for the next 2.1.0 release regards TOPCASED team
Date: 2008-07-26 14:25 Sender: urs zeidler I have now implemented the import of annotations as a profile, and applying stereotypes and their values in the normal model import if the annotations matches a stereotype from an imported profile by name. There are two issues I could not handle by now, the JDT annotation api doesn't support annotation on parameters, I don't know why ITypeParameter is not an IAnnotatable, I have ask in their newgroup without an answer. The other issue seems unresolvable for me, it's about the mapping from annotation to stereotype. Annotation can have field types that are other annotations, there are used to create structured types and they do not need to have a target (a type to apply to) so this end up with stereotypes without an extension and I do not know how I could instantiate a stereotype without an element I can apply it to. Perhaps you have some suggestions. I hope you can use this in one of your next releases. Feel free to contact me, if you have questions, suggestions or issues.
Date: 2008-05-08 12:03 Sender: urs zeidler After reading www.st.informatik.tu-darmstadt.de/database/publications/data/cepa -kloppenburg-aom05.pdf?id=138 I think representing Java Annotations by Stereotypes is the best way to go and feels a kind of "natural" for me. Stereotypes are grouped together in a Profile, and for example "JSR 181"(Java Annotations for Webservice) is such a kind of Profile. So importing Annotations, creating a Profile would be a separate task. In the normal import only applied Profiles could be processed, which means only in the Annotations defined by an applied Profile where imported by applying the corresponding Stereotype, and set its values. I think the jdt people will integrate Annotations in eclispe 3.4 so grepping this information would be easy, no APT or parsing. As my current project makes heavily use of Annotations, and I want to use the code as the primary model, I would implement this as well. greetings, urs.
