JEE Status Meetings/2010-01-07
- Carl Anderson
- Chuck Bridgham
- Rob Stryker
- Jason Sholl
- Jason Peterson
- Rochelle Raccah
- Kaloyan Raev
- Roberto Sanchez Herrera
- Diego Michel Sahagun Ramirez
Java EE 6
- The Java EE 6 xsds are now publicly available - see CQ2982 and bug 262038
- EJB 3.1 bugs of note: 241667 241668
- Java EE Tools plan
- EJB Tools plan
- List of Java EE 6 bugs that need to be rolled into the WTP 3.2 plan
- Make export operation pull from wst.server APIs to reduce redundancy and inconsistancy 265798
- Allow simple but extensible Virtual Component Framework traversal 296764
Carl: First we have approval to get the Java EE 6 xsds into our WTP plugin and XML Catalog.
Kaloyan: We are working on EJB 3.1 support - I started working on it, but we found out that the Glassfish Server Adapter has already made these changes, and will contribute it.
Chuck: Wasn't some of this already done in bug 241667?
Kaloyan: The patch that I already submitted handled 3.0 EJB, but for 3.1 there is a special annotation that needs to be added. This is already in the Glassfish Server Adapter, we just need to get them in. Also, we are glad to get these in because we know they will be correctly implemented, due to who is contributing it.
Chuck: And these will get in soon?
Rochelle: We are working on getting approval to let us move our code down.
Chuck: Let us know if we can help at all.
Kaloyan: The next bug is along the same lines.
Chuck: How soon will those make it in? What is the cut off date for M5?
Carl: Jan. 21/22 is our shutdown.
Rochelle: We might not make it by then.
Carl: Any bugs to discuss in the Java EE Tools or EJB Tools plans?
Chuck: We need to go through all of this and verify the milestones and target things appropriately.
Kaloyan: We are finishing up our proprietary commitments and will soon be freed up to do more WTP work.
Chuck: I think we need commitments on these in the next couple weeks- it is getting late.
Rochelle: Do you guys need the Servlet/Filter/Listener support as well?
Chuck: Carl, has this been done yet?
Carl: I don't believe so.
Rochelle: We can look at adding those into the process. We have a couple more wizards- one is to create EJB timers, the other is to create restful web services from 3 different patterns. Is that of interest to you as well?
Chuck: Can you create bugzillas for these, and send the last one over to web services?
Kaloyan: Rochelle, can you summarize in a short note what features might be part of your contribution? I often use the glassfish adapter for testing, but I am not sure which is which.
Rochelle: If you download the glassfish adapter, and then go to New->Other->Glassfish, the ones that say Java EE 6 are the ones I am talking about.
Carl: Let's move ahead to virtual component.
Rob: Right now I have a big patch to move deployables over. There are some ambiguities, and some unit test changes. My opinion is that all of the changes to the JUnits are necessary and proper. Carl, you mentioned that, rather than changing existing classes drastically, I should create new classes and make the deployable classes use those instead.
Jason P: Bugzilla 297653 ... migrate deployable, right? We need to update this agenda item.
Rob: Running the JUnits is still an issue for me.
Jason P: I want to look at what has most changed in the tests.
Rob: One of the biggest changes is that the module name is now just for display purposes. A lot of the unit tests check the name, and the name can change without breaking behavior. The id has to remain the same. So I changed the unit tests to check the id rather than the name. Another change is EarVirtualFolder, I have to not delete it.
Carl: Yes, it needs to be marked as deprecated and wait 2 releases.
Rob: And I need to create the new classes instead of radically changing the existing ones.
Jason S: I'd like to recommend using FlatVirtualComponent as the name of the API.
Rob: That's a fine idea. We were struggling to find a good name for it.
Chuck: Jason P. is working on this full time this milestone. A question about testing: we are lacking in some of the JUnits for the deployable path, but now we can add some deployable tests as well, right?
Rob: The number of children also changes some times. For instance, some items that were just resources will now be child modules, and will be treated as such.
Jason P: Shouldn't utility modules be just resources, and not child modules?
Rob: Utility modules should still just be resources. If I made that sort of change, that would be nonsensical to me. Other modules will be moreso correctly identified.
Chuck: Sounds good.
Rob: Now, for the Flexible Modules - bug 290041 - how many issues are left to be handled?
Chuck: As far as I know there are some things like the multiselect in the new project reference, that's not in.
Rob: For the non faceted projects, why are we trying to do that? Are we trying to convert them or somesuch?
Chuck: Customers have asked for that.
Rob: We might want to go just the generic file set route.
Chuck: That would mean we wouldn't even have to do the conversion. We might want to separate that out to its own bugzilla. Also for the customization of Add ref dialog, we would need to add stuff in to specify whether it is being added in as a web library or a manifest entry.
Rob: Perhaps the web one could filter out the existing add project wizard and put in its own custom one?
Chuck: I was thinking of going that route, and then put in something to choose which way to add it at the beginning. And it is not even the add project, it is really the add reference itself- any of those could be either/or. It only gets complicated when you try to add two projects as web lib, and one as manifest.
Rob: They will just have to go through the wizard twice, then.
Carl: I don't think Angel is on today. I don't think we need to go through the Server Tools Enhancements.
Rob: He needs to be made aware of the JUnit/deployable changes.
Carl: Anything else?
Chuck & Jason P: Konstantin's Java facet changes are a concern. We need to continue the discussion. We do use the string to compare the facet version at various places in Java EE Tools. Our adopter product also has the requirement that we are backwards compatible with at least one previous version of WTP.