Difference between revisions of "JEE Status Meetings/2009-10-15"

Latest revision as of 12:50, 15 October 2009

Attendees

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

Agenda

Java EE 6

The Java EE 6 models are attached to 252615

Java EE Tools plan

EJB Tools plan

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

Flexible Modules

Replace Existing JavaEE Dependencies page

Bugs marked with the Flexible Modules whiteboard entry

Other topics

Minutes

Carl: I attached the Java EE 6 models to bug 262515. I did 3 attachments because of size limits for patches

Kaloyan: 1.6 megs- this is huge.

Carl: I also worked on tweaking the EJB merged models - the version ID was not being merged.

Chuck: Thanks.

Jason: After today's build, can we check everything into HEAD and then work on getting it into next week's declare?

General agreement

Chuck: Kaloyan - can you review this and work with your EJB code to get the merged model stuff working for EE 6?

Kaloyan: We may not be able to get to it this week - other developers are busy on other items

Chuck: How much more can we get done this milestone?

Carl: We have two more weeks to get things into this milestone

Chuck: Looking at the committed list for this milestone, it looks like ContentType is still remaining to be done.

Jason: When you create a new EE 6 project, it puts in an EE 5 header in the DTD. Can we fix that?

Chuck: Once we flush out the JUnits, making sure the EE 6 models are being created correctly, there shouldn't be a problem with upgrading that.

Carl: How are we doing with replacing the Java EE Module Dependencies w/ the Module Assembly page?

Rob: What were the use cases again?

Chuck: Everything is covered with the core page that is there today except for editing the EAR lib dir. But maybe we shouldn't start with this one. I was reviewing the derived API bug yesterday, and I ran into an endless loop scenario.

Rob: Really? That sounds like a bad bug.

Chuck: Literally, just create a web project with an ear project, and you have an endless loop. It didn't look like the current implementation makes use of this.

Rob: No, I changed the API first, and then I was going to change the code to make use of the API. Other things I have been working on: I put a request to servertools to put add some API. I am thinking of adding in an API that says that this module adds classpath entries- that would be useful at the Java EE level. It could also be useful if I add modules that are not Java EE but that do add Java Classpath entries. I haven't looked at the label provider problem.

Chuck: You gave that to me. I got a simple one done. I haven't had time to get to an advanced solution, which is what needs to be done. I hope to get to it after the models.

Rob: The label provider isn't that huge- it is just a better provider of the information that is there.

Chuck: I can release what I have done so far.

Rob: That would be fine. But we do need to add an extension, so that random virtual components can do what they need to do.

Chuck: Going back to replacing the Java EE Dependencies page: 1) add a way to change the EAR lib dir

General discussion about lib support - defining & adding to

Jason: When we do the label provider for the EAR, we could change the icon to show that it goes into that folder

Chuck: That seems like a regression- today, there is a check box.

Carl: Didn't we talk about extending the wizard for adding a jar so that it shows up there?

Rob: That can be done, it is really simple.

Carl: Didn't you already do something like that for Web already?

Rob: The wizard page can handle that- the default dir can be specified.

Jason: And we should have the same sort of rule for projects as well- if you add in a utility project, it should go into lib. I think an overlay decorator would really help - to let the user know that the item is in the lib dir.

Rob: The overlay decorator would have to be specific to this page.

Jason: I think if we did all of that, it would give us a nice story for the EAR.

Chuck: Editing the lib dir, were we going to move that somewhere?

Carl: I had said I would open a bug about moving it, but I don't see it. I'll go back into the minutes and do that.

Jason: We should hook that action back into the properties page.

Rob: So, now that I've added the derived stuff, and start using it, things that are not persisted would be considered derived. So references that are not currently references, such as binary files in your EAR, those would not show up in this page. I could have it so that 1) if it is a derived reference, you can't edit it, or 2) we don't display derived references.

Chuck: I think that, until we work on our content provider a little more, the proper solution is to not show it.

Carl: Any other topics?

Rob: There was a bug, where there were runtime paths that were being ignored by virtual components. If you tried to set the deploy path on the reference, it was being ignored, so I put the deploy path onto the component. I've figured out since then that the fix that I did was completely nonsensical. It was added on the virtual component, it should have been added on the reference.

Jason: Once we figure out what we need to do to properly fix it, we can rip that out.

Rob: I'll find the bugzilla, and alert you guys.