JEE Status Meetings/2010-08-05

Attendees

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

Agenda

Flexible Modules/Deployment Assembly

Deployment Assembly Bugs/Enhancements

classpath tagging and issues with new container reference system 319650

utility project -> classpath container scenario appears to be broken 319654

new deployment assembly ui packs jars in jars 320411

Adopters should be able to hide some default options from the 'New Reference Wizard' of the Deployment Assembly page 321635

Doc cleanup: Java EE Module Dependencies does not show in Helios 320897

Circular dependencies of modules

Out of spec module dependencies

Bugs marked with the Flexible Modules whiteboard entry

Java EE 6

What do we want to do for WTP 3.2.2?

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

Glassfish Java EE 6 wizards

Java EE Tools plan

EJB Tools plan

Other topics

Server Tools Enhancements:

293742	APIs completed in 3.2. UI part has to wait for next release.
286699	This is a bug. We plan to fix this in 3.2

Minutes

Carl - While we are waiting for Konstantin, let's talk about the plans for WTP 3.2.2 and WTP 3.3

Kaloyan - 3.2.2 should be mostly bug fixes

Carl - I am going to try to get hold of Ludo again to see what the status of the Glassfish Wizards is

Chuck - in the maintenance release, the main topic will be the cleanup of the Deployment Assembly

Kaloyan - perhaps support for OSGi enterprise could be a topic for 3.3. There is currently no movement on the tools part recently, but we at SAP are investigating. Perhaps we could convert a dynamic web project to a web bundle so one could use WTP tools and PDE tools at the same time.

Chuck - that seems like an obvious first step. I know we are thinking about it but I personally don't know where it is in the process.

Chuck - Even though Konstantin has not joined, I would still like to go through the list. Bug 319650

Rob - Another user recommended an editor that focused just on the web or utility project. Where would we hang that?

Chuck - we definitely are mixing some classpath references on that first page. It would seem clearer to move these (or hang the new dialog) over on the manifest page. It is more related to classpath.

Jason - I don't think we should put these anywhere near the manifest page. One good point that Konstantin has is that the current Classpath Container stuff (both web app and ear) are not that dynamic.

Chuck - are we literally absorbing these classpath containers on export/deploy?

Jason - yes. One way to resolve this is to stop adding it to the classpath containers, but add it straight up to the classpath. I believe that that would address his point #2.

Chuck - I agree. If they add a container, we should display it and add it to the classpath. But we still need a way to point it to a specific location.

Jason - We could possibly hit all of Konstantin's points if we did all of that.

Chuck - Not really for #3.

Jason - I think it is straight forward for a web project. I am not sure if we can even do that for the EAR case. The EAR is not a Java project. The way we are doing it right now is mapping it to the lib folder, and thus any module in the EAR would get all of that.

Chuck - I have questions about the use cases. Essentially this becomes a MANIFEST entry, unless you are doing Java EE 5 or later.

Carl - but even then, you want these to only appear to certain projects. They would appear for all modules if you add them to the lib folder.

Jason - one of the other things that was mentioned in one of the other bugs- if you have a collection of utilities that work together well, there is no way to express that.

Chuck - we didn't have that before, did we?

Jason - I think that may have been the classpath tagging he was talking about.

Rob - it still works that way today. The only thing they don't like is the UI.

Jason - In the UI, you still get the list of everything. Nothing is scoped to a project.

Rob - Yes. API-wise, it is all still there. UI-wise, this is not correct.

Chuck - What we are saying is that there is no way to pull one of these into an EJB project and have it all just work.

Rob - Is there a test case?

Chuck - There should be. But back to the tagging issue: I don't have any answers here. Rob, you are stating we could hook that dialog somewhere else and then add some text to clarify what it is doing.

Rob - I see that the participant is already there. I guess I can still look to see if the EAR project is still marked as a receiver, but I would have to look. I think it all works, but there is no test case.

Chuck - I think that with the flexibility we provided here, we need to make sure each adopter can have they flexibility that they need. I believe we need to continue to offer the different types of references, and each adopter can choose to use what they want.

Rob - we may also want to look at the FlexProjDeployable - we need to put a way in such that adopters can have a meaningful effect on the content/output.

Chuck - Bug 320411 - towards the bottom - the assembly of references that are outside of the project.

Rob - Konstantin is using the page incorrectly. I suppose it could be UI error, since he didn't understand that adding it there would not do what he wants.

Rob - Where should we put that classpath tagging?

Chuck - the ultimate place for it would be an extension on the JDT preferences page. We would have to work with them.

Jason - I don't think we are ever going to get them to do that.

Chuck - If we ultimately convince them to allow an option that we can hook into- you really still need to be able to add an entry into the component file and the mapping and all of that.

Rob - If you tag something in your classpath file and it is not in the component file, that will work. If you tag it with ../, it will go into the parent.

Jason - I would like to get off of the classpath and put it into the component file.

Rob - people like Max would still complain. You still have to go to the build path and add it, and then go to the assembly page and add it.

Jason - I wouldn't be opposed to adding things to the classpath from the Deployment Assembly page.

Chuck - You still have issues with other tools adding entries to the classpath - Maven, for example - that need to be deployed.

General discussion of possible tagging solutions

Decision to write up possible proposals of UI changes - Jason will open a new bug

Chuck - I will open another bug to separate out how we handle the classpath containers