Hello, 
  This is a follow up of the WTP 2.0 
  Requirements meeting held on 26 Oct: 
http://wiki.eclipse.org/index.php/2006-10-26_wtp-requiremements-minutes 
  I want to present an overview of 
  my vision how Java EE 5 models should be implemented in WTP. 
  Currently, there are J2EE 1.4 
  models implemented in WTP. These are EMF models generated from the deployment 
  descriptors' XML Schemas of the J2EE 1.4 specification. Overview of the J2EE 
  1.4 models is presented in the following page: 
  http://www.eclipse.org/webtools/jst/components/j2ee/api/j2ee_models_overview.html 
  Java EE 5 models should be 
  implemented in a similar way. The EMF models should utilize the new deployment 
  descriptors' XML Schemas from the Java EE 5 specification. Additional 
  complexity to the models is added by the fact that the Java EE 5 specification 
  uses Java Annotations in addition to the deployment descriptors. Therefore, 
  the problematic shifts on how to integrate these annotations to the EMF model. 
  
  It was a natural approach that I 
  had a look to the JEM (Java EMF Model) project. JEM contains functions for 
  modeling Java classes in EMF. Unfortunately, JEM does not cover Java 
  Annotations at the moment and there is no plan for the future 
  yet:
  http://dev.eclipse.org/newslists/news.eclipse.tools.ve/msg05989.html 
  There are to approaches to model 
  Java Annotations: 
1. Extend JEM with new features to cover Java Annotations and integrate 
  both EMF models (the other one is the one generated from the XML 
  Schemas).
  2. Implement custom utility to 
  parse and index Java Annotation from the source files and make the EMF model 
  (made from XML Schemas) to use it. 
  Due to the lack of any 
  documentation in the JEM project, approach 1. is feasible only long-term. This 
  is why I want to concentrate on approach 2. 
  Now, the Java EE 5 models problem 
  can be split in the following tasks: 
1. Build an EMF model based on the deployment descriptors' 
  XML Schemas. 
2. 
  Parse Java Annotations from the Java files. 
3. Index the parsed annotations in a way 
  they can be easily retrieved. 
4. Make the EMF model to be influenced by the available 
  annotations. 
5. 
  Update Java Annotation with changes on the EMF model. 
  Task 1. Build an EMF model based 
  on the deployment descriptors'' XML Schemas. 
This can be done easily with the available 
  toolset provided by the EMF project. The EMF model is generated by the XML 
  Schemas for the Java EE 5 deployment descriptors. A problem appears if we want 
  to split the generated classes in separate packages for better structure: 
  
  http://www.eclipse.org/newsportal/article.php?id=20770&group=eclipse.tools.emf#20770 
  However, this problem is solvable 
  at least with manual refactoring of the generated classes. 
  Task 2. Parse Java Annotations 
  from the Java files. 
Here Java files can be: 
  - Java Class files in JAR library in the 
  classpath; 
  - 
  Java source files in the Eclipse project. 
  Java Annotations from the Java 
  Class files can be easily parsed using the Sun's Java Reflect API. 
  
Java Annotations 
  from the Java source files can be parsed using the Java DOM/AST API provided 
  by the Eclipse JDT Core project. The latter API models the Java source code as 
  a structured document. There, annotations are treated as member modifiers 
  (like public, private, static, final, etc.). There is a function that checks 
  if a modifier is an annotation.
  The parser utility will listen to 
  events to trigger the parsing process: 
  - ResourceChangeListener/Event - 
  notifies for resource changes in the workspace: project open/close, files 
  added/deleted, etc;
    - 
  ElementChangedListener/Event - notifies for changes in the Java Editor. The 
  parser will be notified that the user has changed a java file in the editor 
  and it has to be reparsed for changes in the annotations. 
  Task 3. Index the parsed 
  annotations in a way they can be easily retrieved. 
The parser will update an appropriate 
  structure with the added or removed annotations. The structure should allow 
  quick and flexible way to retrieve the indexed annotation. For beginning even 
  an ArrayList that holds references to the org.eclipse.jdt.core.dom.Annotation 
  objects is enough. Annotation objects hold references to the parent Java 
  members and parent workspace resources and that should be all the information 
  we need. Of course, the ArrayList is far away from the optimal solution and it 
  should be optimized later with a better structure. 
  Task 4. Make the EMF model to be 
  influenced by the available annotations. 
The generated EMF model from the deployment 
  descriptors' XML Schemas will be modified in a way that it not only looks into 
  the XML data, but also looks up the Annotation Model utility for the 
  corresponding annotation. If there are such annotations indexed, the EMF model 
  will update it state appropriately. The Annotation Model utility also has to 
  provide notification framework, so the EMF model to register a listener and be 
  notified with events on changes in the annotation model. 
  5. Update Java Annotation with 
  changes on the EMF model. 
Properties in the EMF model now declared in two sources: XML files and 
  Java Annotations. When this property is changes it has to be updated in the 
  same source. If the property is declared in XML then its new value has to be 
  updated again in the XML file. If the property is declared as a Java 
  Annotation it has to be updated again in the same Java 
  Annotation.
  To achieve the above, the EMF 
  model has to be changed in a way that it remembers the source type of each 
  property. 
Updating 
  Java Annotation will be done again using the Java DOM/AST API. 
  
  This is the overview for the 
  moment. I want to here your comments. Especially, I want to hear your opinion 
  about the "Extending JEM" <--> "Custom Annotation Model utility" 
  dilemma. Due to the lack of documentation, my knowledge to JEM is not enough 
  and I cannot estimate the effort to extend it with Java Annotation support. 
  This is why I prefer the latter approach that I have described in more 
  details. 
  There are no comments about the UI 
  from my side for the moment. Here your comments would be also interesting. Do 
  we stick to the Deployment Descriptor node in the Project Navigator? What 
  features would be needed there for future enhancements?
  Greetings, 
Kaloyan Raev 
Senior 
  Developer 
NW AS JS TOOLS JEE (BG) 
SAP Labs Bulgaria 
T 
  +359/2/9157-416 
mailto:kaloyan.raev@xxxxxxx 
www.sap.com 
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev