Minutes of the JEE 5 Working Group meeting Jan 04, 2007

Teleconference on JEE 5 Support in WTP Jan 04, 2007

Attendance

• Chuck Bridgham
• Shaun Smith
• Kaloyan Raev
• Hristo Sabev
• Jesper S Møller
• Paul Fullbright
• Dave Gorton (BEA)
• Paul Andersen
• Neil Hauge
• Rob Frost
• Naci Dai

Agenda

• Action Items:
  • Chuck Bridgham- Review EMF 2 XML patches [160567,160569,164246]

• Review M3 & M4 status for EJB 3.0 Facets and Projects

 **Bugs:[167101,167097]

• Review JEE 5 Model Extension Point Design (Hristo Sabev)

 **Bugs[167807]

• Other items

Minutes

Action Items

• CB: I have applied the patch for 164246 code patched - I will release the code after some testing and M4 is out.
• JM: I am working updating the pacth for multiple attribute values and references, and adding some tests.
• CB: We appreciate the work you have done. Is multiple attribute work additional - Can the defects be merged?
• JS: They can be (tracked) using the same defect, but dependent objects needs to be more general.

Agenda Items

• CB: EJB3 facets are in the code and ready to be tested, We will release it M4 is out. Used Kosta suggestion to specify the version tag and fixed the problems.
• ND: have you been able to compare what you have done with JBoss' defects for EJB3. Max send an email to the dev list.
• CB: Yes, I think they are doing smt similar. They had some requests for server modules (not to be confused with multiple JEE modules in a project).
• ND: We should ask Rob Strykey for JBoss to merge these defects so that we can track the request. We should get Tim and Kosta involved.
• ND: Thanks to SAP and Hristo for providing the rather extensive draft document for JEE model extensibility (see bug:167807). Can you please walk use thru the doc.
• HS: It is still very draft - The document presents a single model to provide structure - a graph, and with nodes in the graph that can link corresponding model elements to semantics (i.e. business interfaces). This model should be common to all projects (i.e. package structure, than xml, certain classes are EJBS, other are webservices). Each node should be extensible. Contribute nodes and extensions. Basically, we will have a universal tree - add extensions to the tree. ModelBuilder creates the tree, adopters create extensions for the elements. Use facets to filter the projects. There are categories for organizing models. Extenders can specify the elements of the tree does their extensions apply to.
• ND: So, would our existing EJB model would be an extension (node) in this tree?
• HS: Yes
• ND: And, would we use this tree for things such as JEE explorer?
• HS: Yes views should be able to use the tree - Maybe with the project explorer. Another issue is synchronization of the underlying resources with the model elements and the tree. I think EMF model has to be regenerated for this case.
• ND: This proposal is rather extensive. There are many good things in it, for example the ability to attach different modeling technologies (other than EMF) I do not think we would be able to absorb it into WTP by 2.0. However, we should understand what is involved in making the existing models co-exist with it
• DG: I agree
• CB: Builder is a good direction to go. But a lot of work to support model element. This model is basically a DOM tree is it correct?

HS: It is more than DOM, for example it can support navigation, and we should not have to change to much API. Configuration issue is not clear to us. We need more examples to understand what is needed for model elements.

• DG: Does this suggest new public APIs for WTP models?
• HS: Yes I would think so... New models can inherit from existing WTP modeld but we should supply other models too. So there can be other modelling technologies (non EMF). And support things like navigation.
• RF: Impact on existing code that uses EMF models is a concern. Is there a path for incremental adoption.
• HS: It should, we do not have to touch the existing code. New extensions can build on it.
• CB: It would help provide different ways to support thinhs like XML deployment. We should definitely look at what is available for supporting models lik ethis.
• RF: Existing modelling technologies and support things like rendering.
• JM: Is it good to move away from EMF?
• HS: External editors (outside eclipse) EMF model needs to reconsructed sometimes?
• JS: Adapters solve that problem (EMF 2 XML), or reconcilliation.
• CB: That is not specific to EMF. We have listeners to do that for EMF - We recreate the model.
• HS: We are not against EMF, but need other tech to be included in models (i.e. Annotations)
• CB: Our edit models do that - track multiple resources on a single model. Load and sync collectively. This is EMF specific but not generic for all model tech.
• RF: So this can be applied to annotation model of Java files
• CB: Annotations are complicated (i.e. override vs extend). We may need smt to consolidate.
• RF: Evolution of the edit model should be looked

• ND:- Thank you for attending this call. Please comment on the SAP proposal using bugzilla. We will meet again next week to discuss it.

Comments

Please add your comment here: