| [dali-dev] Re: [wtp-dev] Java EE 5 models design overview |
|
Hi Kaloyan, >>May be a common package for annotation processing that is placed down in org.eclipse.jst will be of great benefit for many WTP components. This is something that we and others have been interested in for quite some time. There are some basic issues in the JDT core that have been around for a long time that make things difficult with regard to annotation support. Starting at the beginning, take a look at bug 79112*. This bug requests basic support for annotations in the Java model. This is really where support for annotations should begin. What we have created in our util.jdt package was necessary to dig into the AST and JDT to support annotation configuration. As you have seen, even at the AST level, annotations are not represented as a first class element, as noted in bug 106108**. As you can see from these entries, it is fairly difficult to manage annotations given the underlying model support. The JDT team is now actively looking at these issues. Once (and if) they are resolved, it would seem reasonable to take the next step to including specific API's for managing annotations and their complexity. As a side note, please CC yourself/vote for these bugs. The more organizations and projects that are pushing for annotation support, the better chance we have that something will get done. Also, as you mentioned, JEM support would be extremely helpful, but I don't know how likely this is until the above issues are resolved. You may want to look at what the APT team is doing as well for a more comprehensive view of what is happening regarding annotation support in the JDT core. Enhancement 154110*** describes some of their future work. >>Can you provide some overview what is covered by the Dali tools for annotations and xml descriptors processing? Sure. In our 0.5 stream, we have the ability to read and write a large number of JPA annotations with some configuration limitations. The focal point of our annotation management support consists of a collection of utility classes that generalize the effort of reading and writing annotations. These utilities try to cover the reading and writing of all of the various forms that annotations may appear in (at least for JPA), isolating and hiding this complexity from our model. Beyond this we have to manage annotation change from the editor and change from our UI. We listen for changes and update our model based on changes to JPA annotations in the java source. We also push changes to the source from our model by editing the AST via the utilities. This general annotation support is currently being refactored to fill in some of the holes in our previous support, in addition to simplifying the code and the general process of working with the Java source. Our XML Descriptor processing is specific to the JPA XML Descriptor (orm.xml) and is fairly basic at this point. We can read and write a small number of properties to the orm.xml but have been struggling with the complexities of the EMF to XML translation process. We are using the EMF to XML Translator framework and have had some success with it, but have also had numerous setbacks. It is a major learning process, and I can agree that it is not for the faint of heart, but it still would seem to provide many advantages over starting from scratch. We are probably spending most of our time trying to make the Translator framework do what we need it to do at this point. I think a lot of this complexity has to do with the fact our project requirements involve a rich UI for editing these artifacts. This is a new thing, since the artifacts for J2EE 1.4 support were all XML based, and were configured by the user via the generic WTP XML editor. As a result, the existing WTP code doesn't solve a lot of the problems we are running into. Given our requirements, there are no easy answers when it comes to modeling and persisting JPA meta data. The model for JPA annotations isn't the same as the model for the XML Descriptor. Both artifacts are persisted via different mechanisms/frameworks. The mechanisms being used for this purpose are both under development, and may not have been previously exposed to the demands of our requirements. I think that the general process you describe for supporting the Java EE 5 models (option 2) is a good enough place to start. You may find out (like we did for EJB3 - JPA) that the properties in the annotations aren't necessarily a copy of the properties from the XML Descriptor, so this is something that could cause problems and is good to be aware of. Beyond that, as more requirements come in it will become more clear if the models you describe will be able to meet those requirements. Neil * - https://bugs.eclipse.org/bugs/show_bug.cgi?id=79112 ** - https://bugs.eclipse.org/bugs/show_bug.cgi?id=106108 ***- https://bugs.eclipse.org/bugs/show_bug.cgi?id=154110 Raev, Kaloyan wrote:
|