JEE Status Meetings/2009-09-17

Attendees

• Carl Anderson
• Jason Sholl
• Kaloyan Raev
• Chuck Bridgham
• Rob Stryker

Agenda

Java EE 6

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

Java EE Tools plan

EJB Tools plan

Flexible Modules

Bugs marked with the Flexible Modules whiteboard entry

The module assembly page is in the build!!!

Need to add the Module Assembly page to the M2 New & Noteworthy

Minutes

Carl - review of Java EE 6 bugs, update of the jeetools 3.2 plan

Kaloyan - we moved the facets to M3, since it is too late for M2

Carl - we hope to have the models in during the M3 timeframe, as well

Discussion about getting to the project plan

Chuck - let's go through the themes -first, Ease of use

Kaloyan wants to commit to doing 239196 for WTP 3.2

Kaloyan will defer 198937 - unless someone else wants to contribute

Kaloyan - 248623 should be redone/deferred

Jason - we need to phase out the Java EE Module Dependencies page

Chuck - is there a bug for that?

Carl - no.

Discussion of Rob's Module Assembly page - what bugs are still relevant, and which ones should be closed.

Rob plans on doing something similar to bug 248623 for his page, but there still may be relevant parts of 248623

Chuck - I think we need to have a separate bug opened for the Ear wizard specific part that needs to be reworked

Kaloyan will investigate reworking that bug

Review of deferred items, discussion of 228625

Jason - this sounds like a perfect candidate for the LTK refactoring framework. No matter which part you select, the other

part can be done.

Chuck - do we want to move both of those to proposed?

Jason - yes

Kaloyan - I can open one bug to cover both portions of this, and then I can duplicate the other two against that.

Jason - once servlets are done, it should be easy to do listeners and filters as well

Discussion of bug 13

Chuck - Carl, you are planning to get the EE 6 models into M3, right?

Carl - yes

Chuck - Kaloyan, you are going to get the facets into M3, right?

Kaloyan - yes

Chuck - shouldn't we move some of the others to proposed? Perhaps all?

General discussion about the history and how they are still in the same state they were left in for WTP 3.1

Carl - I will target the schemas enhancement once the schemas become public

Chuck - 252616 - should we move that to proposed?

Discussion about proposed items, the jeetools plan and the ejbtools plan, and how the plan is dynamic

Chuck - We really need to make sure our Model Provider framework is good enough/extensible enough to cover models that adopters provide

Carl - including non-Java EE models, right

Chuck - yes. This should not be Java EE specific. I would much rather take a look at that than create a bunch more extension points.

Kaloyan - these are two different issues- one is the extensibility of the model, the other is how the wizard is using the model.

Jason - so we might need an additional generic control in the wizard(s) that might refer to an additional model?

Kaloyan - yes.

Chuck - any others that are not on the plan?

Carl - I tweaked the bugs so that between the EJB plan and the Java EE Tools plan, they now all show up.

Chuck - is there anything else we need to cover?

Jason - Rob opened a bug a while back about archives

Rob - Exporting and publishing use two different APIs. We need to make sure that export draws from the appropriate model. Bug 265798

Jason - I think it is the perfect time to start looking at this. At the same time we are adapting the Java EE 6 models for IArchive, we should do this at the same time.

Chuck - is this something we would want to do pretty soon?

Jason - yes, we can start already

Chuck - should we commit to this in M3?

Jason - yes

Rob - Jason, we need to talk about this. With the way we are discussing extending VirtualResource, we'll need to discuss this.

Carl - would that go under the Other category?

Jason - yes

Chuck - any other deferred ones?

Jason - bug 242736 - this keeps coming up. I think we ought to call this out as helpwanted

Carl - next on the agenda is Flexible Modules

Rob - We can't get anything more in Flexible Modules into M2. One of the items I want to focus on is the derived status of Virtual Resources

Carl - Do we want to add Flexible Modules into our plan?

Chuck - yes

Rob - The derived status of Virtual Resources is important to our wizard - what we want to do is add in the container reference. One of the key things to be able to move in that direction would be an extension point - bug 282869 - that one is very important because it opens everything up, and once you open everything up, it gets scary, since you aren't sure what your EAR would do. But it would allow things like adding a reference to a Java project that isn't a Utility project.

Chuck - Right, a bunch of different resolution schemes. We just need to make sure that this is planned for early in the milestone so we have time to flush out the existing scenarios. I am worried - we need to make sure we don't break adopters

Rob - this first part isn't the scary part. Adding in class folders and other virtual references/virtual components is when it gets interesting. The other thing is modifying MANIFEST.MF on the fly- should we be doing that? Is that even appropriate?

Jason - I don't think it is appropriate. Perhaps at the server adapter level.

Rob - can someone sum that up for me? Why are we doing that?

Jason - this is something BEA did that they were doing to try to help users do what they were attempting to do in modifying the classpath before it is deployed. There is another piece that is not in WTP that links things together properly. The support that is in WTP doesn't work by itself.

Chuck - this is kind of a vendor question. IBM always sees the artifacts as static artifacts- there is no magic that should happen when you deploy. I would rather see that when you are editing.

Rob - Is that controversial? Can we just change it?

Jason - we need to get others involved

Carl - we need to make sure our adopters remain happy

Rob - I have also been using my time to figure out referenced components that some components may want- references from EJBs to jars and such. The reference itself is type consumed, so that when it is pulled together, the referenced item is just pulled in automatically and doesn't appear separate.

Jason - I agree- sounds good.

Chuck - I think I need more details. It sounds good to me.

Rob - I think we had this discussion when Konstantin was on the line. Basically a consumed reference is the same as what a wb_resource tag should be. This appeared to me to be an easier method to do it. In the future, if we want the two types to use the same handles, we could look into that.

Chuck - When you are declaring different consumption models, are you setting up different resolution rules, as to whether it is consumed or not?

Rob - the extension point sets up a handle, a reference. If the customer doesn't want that in there, he can go to the Module Assembly page and remove that reference. We can add in validation, warnings, and such at a later time. The ultimate goal is to make these factories standard - we add in the reference ones, and they should be good enough for most cases. Now, when we get to export, we will investigate pushing all of this into a more unified layout.

Chuck - and we will get this into M3? At least the beginnings of it?

Rob - yes. And since I am already making those pieces in my own code, I can just move them over.