JEE Status Meetings/2009-08-27

Attendees

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

Agenda

Java EE 6

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

Flexible Modules

Bugs marked with the Flexible Modules whiteboard entry

Short discussion of plan to clean up isSingleRoot without breaking adopters 284187

What needs to be done to get the complete module assembly page into a build

Other topics

Status update for bug 287452 for WTP 3.1.1

Minutes

Carl - run through last week's minutes Java EE 6 - bug 252613

Chuck - this doesn't include any new facet types, just upgrading the previously defined ones

Kaloyan - yes

Jason - we want to revisit the patch - some things have changed

Carl - when do we want to put this bug in? We probably want to put it in at the same time as the models and possibly the import/export wizards

Kaloyan - I don't think this will break anything.

Chuck - we did have the notion of a default facet version. There are some operations out there that, if you don't specify the version, it will take the default...

Kaloyan - I think the default version is still Java EE 1.4

Carl - when do we want to put this in?

Consensus - M2

Carl - 252615 -

Kaloyan - do we know the differences?

Chuck - we are hoping that this will be addative. Do we want to break out the connector model piece? That is more of a significant change.

Carl - we can do that

Jason - keep in mind, the connector model requires that the other models be done first. Also what about the facets for web fragments and EJB lite?

Chuck - 272014 is for web fragments

Carl - 272016 was supposed to be for EJB lite, it just has a bad summary

Chuck - going back to 252615, let's target that for M3. We also need to look into the schema files

Jason - let's try to target that for M2

Chuck - yes, let's make that an M2 target

Carl - anything else to target at this time?

Jason - I think we need the fragment facets before/with the model support.

Chuck - the EE 6 models- that is moreso an extension of the existing models. The other models are separate, right?

Carl - that is what I thought

Jason - then we will need a separate bug for those models, right?

Chuck and Carl - Yes.

Jason - the web-fragment.xml is the same as web.xml, except that a lot less is required.

Chuck - it definitely should be a separate bugzilla, for that part of that model

Jason - there will be 3 separate bugzillas and models, right?

Chuck - yes, one for the old models, one for connector, and one for web fragments

Carl - what about EJB lite?

Various discussion about EJB lite

Chuck - I don't think that EJB lite needs its own separate model

Kaloyan - I still don't quite understand EJB lite

Chuck - EJB lite is moreso a declaration of what support is in a container. EJB lite does not support CMPs

Jason - Session beans. No remote interfaces, no jax-ws or jax-rpc, no timer services, no BMPs, no CMPs, etc.

Kaloyan - so the combination of EJB 3.1 facet and EJB lite facet makes an EJB project...

Jason - we could go the route of having a separate EJB Lite facet, and then allow upgrade from EJB lite to EJB.

Kaloyan - so this is more like a restriction

Jason - it is really a runtime environment thing- it restricts to a subset.

Chuck - the model ones, let's make them all M3, and do the best to finish them when we can

Chuck - there are other items that need to be brought into the plan... maybe we shouldn't guess at this point.

Kaloyan - There are two ways to package EJB components in a WAR- in WEB-INF/classes and a jar in WEB-INF/lib. The latter is somewhat supported today. What we can do as an improvement - when we create a new EJB project, we can make it so that the user can choose to add the project to an existing web project. We actually have that done very easy.

Chuck - that is close to what we were thinking, as well. As Jason was saying, the project that we are developing that would be packaged in the WAR is the same as any EJB 3.1

Jason - there are some restrictions- you can only have one of these things in a WAR. You cannot have both an EJB and an EJB jar defined in the WAR. Where it gets kind of tricky is where you can only define one ejb-jar.xml in there- if you have other jars and beans in there that are annotated, it is unclear. And if the ejb-jar.xml says it is complete, can you have annotated beans that are shown?

Rob - is the container supposed to honor that?

Jason - that was still unclear to me after reading the spec.

Carl - any other EE 6 discussion?

Chuck - this will be a product preference

Rob - is that available via generic plugins, or how is this set up?

Jason - you would need a product plugin.

Carl - I am trying to check in 251813 right now, too.

Rob - The one that I have been working on a lot in the last couple of days is the single root bugs. I am going to try to clean all of that up so it becomes more understandable code. Maybe you guys won't like the patch, so we can discuss it, and that would be fine.

Chuck - I would welcome your look on it. I can wait for the patch, and I will comment on it.

Rob - I will provide a patch soon. I am working on the members() method to make sure it returns the proper stuff.

Chuck - which bug is this?

Carl & Jason - 284187

Rob - I wonder about some of the code that is in there, and how adopters will react to my changes.

Jason - what do you mean?

Rob - For instance, the manifest problem that I referenced. You're saying this is single root, where it really isn't.

Jason - I agree that in that instance, it should return false.

Rob - what about the classpath?

Jason - jars on the classpath and nested modules are fine. Other than that, it should fail. For example, loose classes added to the classpath

Rob - this refactor should make it so that isSingleRoot doesn't actually change what is returned... unless they set that flag. But obviously, the goal is to get isSingleRoot to be very clear, and return things in the proper order.

Jason - sounds good to me.

Chuck - sounds great. This is definitely an M2 thing.

Rob - if we can get it into M2, that would be great

Carl - Rob, do we want to discuss the wizards?

Rob - yes. In the Module Assembly page, we added dependencies that were not allowed. Konstantin didn't want me adding in public classes. Right now, let's add this as private API. So I have approval from Konstantin and Angel to copy these over.

Chuck - there was one other issue -the facet

Carl - I talked w/ Konstantin about this... we can make a project into a faceted project, with no facets defined. That should solve all of our issues.

Chuck - is that something we should get in ASAP?

Rob - yes. But I can't commit yet, due to the paperwork processor being on vacation.

Carl - if you can get the private wizard patch out there, I can commit