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.
JEE Status Meetings/2009-08-20
- Carl Anderson
- Max Rydahl Andersen
- Rob Frost
- Angel Vera
Java EE 6
- List of Java EE 6 bugs that need to be rolled into the WTP 3.2 plan
- Bugs marked with the Flexible Modules whiteboard entry
- WTP 3.2 synchronization with Helios schedule and impact on WTP Java EE Tools/WTP EJB Tools adopters
Carl: Announcement about Java EE 6 support plans Review of Flexible Modules bugs 241332 - another critical bug that needs to be fixed
Rob: Bug 284060 - we need to do further discussion on how to proceed before we do this. We need to further examine how Bug 280416 really needs to be fixed - the logic behind the original coding ignores the setting of any module's location other than Utility projects. That is following the spec too closely.
Carl: Bug 277482 - the wst.modulecore.ui plugins have prereqs to other, higher level plugins, for example the servertools.ui
Angel: we can investigate moving those down. Let's open a bug to see about wrapping those.
Rob: Who is going to do this?
Carl: I can send Rob the information on the current CVS location of his plugins
Rob: 276825 is one that really needs to be looked at. Also recently, in our produce, there was a bit of a misunderstanding - there is an EAR project that contains a Web project. The Web project has a deploy-name in it. If you deploy the Web standalone, it gets the longer name. If the deploy is done within the EAR, then it gets either the Web project's name, or else the name specified in the EAR's application.xml/component file.
Carl: This is on purpose, and is somewhat documented.
Rob: In the add/remove projects wizard, it shows the longer name. When you deploy it, it uses the shorter name.
Carl: Personally, I think that that needs to be fixed, but yes we need to address the entire issue.
Rob: So I need to split apart the patch for 276825 to separate those two issues. I am still a fan of allowing extension points for different handles, but we are not in a hurry for 282269. Getting 276825 clarified would be an action item for me, as well as cleaning up 277482. Since we have a smaller team, I assume that we need to expand the resource mapping first, then expand the rest of the
IVirtualComponent work- but we need the appropiate people on the call.
Carl: Last item-
Max: Our biggest problem is that what Rob has been working on has been a big problem for us over the years. We were depending on WTP 3.2 coming out in December. So we are trying to determine what is the best way to put together a release in that timeframe. I am also talking with the Maven guys- this is the same area that they have been trying to get their head around- how to do deployment properly, instead of being stuck with what the J2EE code dictates. We were missing the UI part. Rob kind of "cubbied in" his changes into what we have. Now we have the two separate pages. Do you have any ideas of how to manage that? Our current thought is to add this page in, and if you use that, then don't use the J2EE module dependencies page.
Carl: Would it be of benefit for us to add an extension point or preference to 3.1.1 to hide the Java EE Modules Dependency page?
Max: Maybe. What we want to do is to rely on the current functionality in WTP 3.1 - the flexibility is there, but the UI locks it down. We will be creating modules with more flexibility than is in today's code.
Rob: We are willing to give up some of the automatic classpath and that in order for deployment to work. Is that a good summary?
Max: No. We need that to work in order for the product to work properly. We need to add in UI. If you add in an option to disable it, that will work great for us. But we will be using functionality in webtools core that are not exposed to typical webtools users. Our product will allow for more flexibility than is allowed in the current WTP. I would like to make sure that we don't use features that you are considering dropping, with the claim that "we don't expose that in our UI".
Rob: I think it is always intended to be backwards compatible.
Carl: I think the best way for us to support you would be for us to go forward with putting Rob's stuff into 3.2. Then you know for sure that what you are doing in your extensions are part of WTP 3.2
Max: We just need to be aware of anything that might be done that might alter that.
Carl: One of the biggest ways to make sure of that, is that Rob is now a committer on jeetools and common.
Rob: Max, I put in our old version, which should work the same functionality-wise. It may not look as pretty. In WTP, we are putting it into 4 different plugins, whereas we just have one.
Max: Whatever we do over time in WTP 3.2, we need to back-port into our stuff.
Rob: I am just saying it might not be 100% the same. There may be some minor differences. It is split over 4 plugins in WTP, whereas in ours, it is only in one.
Carl: You say 4 plugins- we only split yours into two.
Rob: Two new ones, and changes to two old ones. Once we start changing core API, those changes will only be in future versions.
Max: Could we use the same plugin/package names in our code? It would be easier to maintain.
Carl: I would think that you could do it, with a plugin version ID is less than 1.0 Also, removing the JEE Module Dependency page- that would need to be done quickly, since WTP 3.1.1 is about to go into PMC approval mode. It may be an extension point or a preference or somesuch.
Carl & Rob will work together to get 277482 straightened out and in the build ASAP.