Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

JEE Status Meetings/2010-03-18

Attendees

  • Carl Anderson
  • Roberto Sanchez
  • Rob Stryker
  • Chuck Bridgham
  • Jason Sholl
  • Jason Peterson

Agenda

Java EE 6

What can we get done in M7?
List of Java EE 6 bugs that need to be rolled into the WTP 3.2 plan
Glassfish Java EE 6 wizards
Java EE Tools plan
EJB Tools plan

Flexible Modules

Replace Existing JavaEE Dependencies page - bugs of note: 303600 303706 304654
Bugs marked with the Flexible Modules whiteboard entry

Other topics

Modules always synchronized 304673 - any update?

Server Tools Enhancements:

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

Minutes

Carl: First, at Tuesday's PMC, Raghu from Oracle brought up the fact that Glassfish still wants to contribute the wizards that are linked to in the agenda.

Chuck: We need to make sure that those wizards fit into and reuse our existing framework.

Carl: I had not heard of a time frame for that yet. Are there other items we want to do for M7?

Chuck: There's the deployment assembly wizard - I know Rob has some patches.

Rob: Bug 303600 - you used to be able to pull up into the EAR things that were lower than the EAR's classpath. There's no UI for some of the classpath manipulation... especially moving something that was up into the EAR down to WEB-INF/lib.

Jason S: I was wondering if we wanted to move this support forward, or if we want to move the management to the EAR's deployment assembly page. That way, you aren't altering the EAR's classpath from a child module.

Rob: That sounds good to me.

Chuck: I agree with that, but we do need to support the current way of doing it, and eventually move off of it.

Jason S: We can code the Deployment Assembly page to discourage future use of it, and instead promote the EAR's deployment assembly way of doing it.

Rob: I would rather that we show this, and then show that it is a deprecated usage.

Jason S: Perhaps with a quick fix to switch it to the new way. Then we could make this a reference from the component file of the EAR.

Chuck: I am just thinking about the use case here.

Discussion about the proposal in bug 303600 and how it really expands support rather than reduce it.

Rob: Alright, we will clearly mark it as deprecated.

Chuck: And then edit wouldn't be active. But, how would users fix this?

Jason S: There is a quick fix right now that does this.

Carl: Just to be clear, remove would still be active?

Rob: No, this is a derived reference. You would be able to edit it and clear the check marks.

Jason S: The usecase here- they want to have a bunch of jars, and they want to be able to dynamically add and remove these jars without updating the classpath. With Java EE 5 and 6, you can just map these to the EAR's lib directory.

Discussion about the various usages of variable references.

Rob: The proposal for the EAR page enhancement - 304654 see screenshot

Chuck: I will review that, let's get this in.

Rob: No UI for variable references - bug 305650 - basically the way that wizard fragment was created was really ugly and not useful. This is important for m2eclipse people. The other thing is the manifest section. The first thing I notice is that you can edit the manifest section. You are not really editing who is contributing it.

Chuck: What you are saying is that you are not really changing the jar in the EAR. OK, I am OK with limiting the functionality here - you can add or remove.

Rob listed off other scenarios that don't appear to work properly in the manifest section.

Chuck: In some cases, we are not editing the .component file, we are only editing the manifest. We need to be clear on what happens when you press OK.

Rob: I need to understand the supported use cases here.

Jason S: Chuck, I think what we need is a separate section for manifest entries, where it is clear that we are moving this reference up into the EAR.

Rob: The manifest section should be really dumb. The references are to jars/libs in other projects.

Chuck: What I was trying to reduce- rather than having to open the EAR, add a utility jar, and then come back here to add the reference, we could do it all here in one step.

Jason S: How about a "Click here to open the properties page on your EAR"?

Rob: We're discussing all of these changes to the MANIFEST.MF, but doesn't that get overwritten at deploy?

Jason S & Chuck: No.

Jason S: The only time this gets overwritten is when that funky classpath stuff that we are trying to deprecate is being used.

Rob: It is pulling thing in. You need to be able to add/remove references, so you need to be able to edit it. Other than a text box that shows what is there, what do we need?

Chuck: We need to be able to add things from the EAR. The old page showed a bunch of check boxes of things available from the EAR that were not yet mapped. It used to be split across two pages, so it was clearer in that way.

Jason S: Now we have the top part, which is the .component, and the bottom, which shows the manifest. We may want to consider reorganizing the page for modules. For other modules, besides web, we really want to emphasize the manifest section.

Chuck: For EJB projects, I hijacked those buttons, and they really do focus on the manifest.

Jason S: I think that is a bad idea. The behavior should be the same for those buttons.

Rob: I am also trying to make this usable by other projects. I just added interfaces so that you don't need to explicitly have Java EE objects to find this information out, such as a WAR in an ESB.

Chuck: Maybe the next step is to do the previous bugs that you mentioned- let me review those and let's get them in. But then, do we have a bugzilla open for the manifest section?

Rob: I opened two of these: 306174 and 305971

Chuck: Is there anything else we want to discuss?

Rob: I attached a patch to the server synchronization bug. I also fixed bugs to have us use Adaptable instead of casts & method calls.

Jason P: We have adopter code where this will help, but we need to do it in J2EEModule and other areas.

Chuck: We do need to make sure that we keep the PMC in the loop on these.

Carl: We are not going to hold this meeting next week due to EclipseCon, right?

Rob: J2EEModuleVirtualArchiveComponent- it has getLinkToEAR - is that really used?

Jason P: There used to be extra methods on J2EEFlexProjDeployable - how does a web project get references to other projects that map to WEB-INF/lib ?

Rob: The specific scenario where the web project is single root?

Jason P: The optimization used to only be in getMembers()... now getChildModules() also is optimized.

Rob & Jason P discussed the implications/ramifications/behavior of the deployables.

Jason S: The way the servertools keeps track of changes, it needs a list of members. It is a noticeable optimization in large workspaces.

Rob: My other optimization will reduce the number of server tools code calls to members.

Rob & Jason P discussed how server tools & Java EE deployable should interact on changes.

Back to the top