JEE Status Meetings/2010-02-25

Attendees

• Carl Anderson
• Rob Stryker
• Kaloyan Raev
• Chuck Bridgham
• Angel Vera

Agenda

Java EE 6

EJB 3.1 bugs of note: 241667 241668 299086

Glassfish Java EE 6 wizards

UI work before M6 ends: 303917

Java EE Tools plan

EJB Tools plan

List of Java EE 6 bugs that need to be rolled into the WTP 3.2 plan

Virtual Component

Migrate JEE export operations to use the FlatVirtualComponent Model 299576 - committed to WTP 3.2 M6

Flexible Modules

Replace Existing JavaEE Dependencies page - bugs of note: 303600 303706

Bugs marked with the Flexible Modules whiteboard entry

Other topics

Server Tools Enhancements:

293742	Discussion continue. Not in plan, yet
286699	Need to review. Not in plan, yet

Minutes

Kaloyan: Singleton bean was in last week, the no interface went in this week. I don't think my team will be able to do the EJB Timer

Carl: I just opened a bug to change the label of the newer bean wizards from EJB Project to something more generic, like EJB container

Kaloyan: I would rather it be changed to Project instead of EJB Container so that it is more generic

Angel: How is this going to work?

Carl: In Java EE 6, Session beans and Message Driven beans can be created in a Web's WEB-INF/classes, or in a jar in WEB-INF/lib...

Chuck: This is just staging work -

Kaloyan: We should do similar work for the Servlets wizard - make the title more generic to include web fragments

Carl: That would be Servlets, Filters, Listeners, yes, you are correct

Kaloyan: All of these wizard pages extend from something common - this label is currently retrieved by an abstract method. We can make that method just return the project label.

Carl: The Virtual Component work is complete now. Flexible modules-

Rob: I wanted to ask what we are going to do for the UI changes I had mentioned

Chuck: If you take away the derived references, it makes it difficult to edit the manifest and see what is happening there.

Rob: Yes, I see it as being a mainline use case that shouldn't disappear. I also feel that the way that the page is layed out is very solid. Perhaps we could add a child property page for these modules?

Chuck: If we had a check box that had "Show derived references" and showed the manifest as well... being able to add and remove those references is important

Rob: That's the whole problem. A lot of these derived references couldn't be removed.

Chuck: That's what I meant by removing it from the manifest.

Rob: But the way the page is currently structured, we would have to change the way the remove button works.

Chuck: I think that is done. In the J2EE case, I already overrode the way it works.

Rob: What I am saying is, if someone clicks on a derived reference and then clicks on remove, it is not the same thing- it is not a hard references. I would rather see a page underneath that shows the manifest and works on those derived references.

Chuck: That's not the way I thought we were headed, though.

Rob: The module assembly page currently shows what is included in the child module- you would now be showing things that are included in the parent but only referenced in the child module.

Chuck: OK, I see where you are going. If it were a separate page...

Rob: The thing that makes it hard is that the way it pulls up from the ear, and pushes things to the ear, was crazy, wild, and weirdly implemented. I could not tell if a change was pushed up or pulled down or what was happening.

Chuck: The old page never changed the EAR. I would entertain now the idea that a user selects a utility project and then it does both things. Perhaps that could be done on a child page. The old page actually showed the manifest.

Rob: In the old page, if your EAR project had a utility project, you could reference it in your WAR. And also, if you added something to your WAR's classpath, there was a way to add that to the EAR.

Chuck: I wasn't aware of that functionality.

Rob: If we just made a second page that was just the manifest page, we could clearly deliniate that this page is how we structure our project, and the other page is entirely manifest.

Chuck: I am not sure if users desire to see one page with their entire classpath.

Rob: This still raises another problem - the classpath user variable - that is stored in the .classpath file. If you push that up to the EAR, I am not sure how the EAR project would have access to that.

Chuck: If we had a second page that actually showed both references and the manifest - would that work?

Rob: I am really worried about how the EAR would show what it is exporting. How would we show that?

Chuck: The EAR stuff should be done at the EAR level. When you open up the WAR module assembly- it is simply visibility into that WAR- you are not pushing up anything to the EAR.

Rob: I know we can't deprecate the usecase of pushing a variable up to the EAR... I would like to. If we could say that the EAR should have this one new reference type...

Chuck: Are you talking about the case where the manifest gets changed on the fly?

Discussion of details of how things are working today, and what use cases we need to support. Bugs 303600 and 303706 will be used to discuss this.

Rob: I also wondered about some work I did for filesets- would WTP be interested in that?

Carl: Bug 303730

Chuck: That's interesting

Carl: The only thing that worries me is that it would need a new CQ, and we are past the deadline for that.

Rob: Another thing - I have another version that uses Remote System Explorer (RSE) to do this using NFS, FTP, and all of that.

Chuck: Do we want to go on to the server stuff?

Angel: 293742 - we are going to get that in soon. For 286699, it might not make it into M6.