JEE Status Meetings/2009-09-17
- Carl Anderson
- Jason Sholl
- Kaloyan Raev
- Chuck Bridgham
- Rob Stryker
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
- 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
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
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
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.