Difference between revisions of "JEE Status Meetings/2009-07-09"

Latest revision as of 12:36, 9 July 2009

Attendees

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

Agenda

Proposed Scenarios

• Select projects (add/remove)
• Select jars (or other resources) inside the workspace (add/remove)
• Select jars (or other resources) outside the workspace (add/remove)
• Editing the deployment path/archive name

Content of the Module Dependency Page (Note that this is focused at EAR module assembly)

• Update on Rob's latest work
  • Rob reduced the number of columns to 2
  • The UI can now change deploy path *and* archiveName in the descriptor component.xml file
  • Both deploy path and archive name are editable in column 0 in the editor as one path, which is then separated during the operations
  • Rob has not added UI for adding wb-resource elements as there was no general consensus on whether this is a desired feature
  • Rob has not migrated the buttons into a multi-page wizard yet as there was no clear agreement on what should go into it
  • Current screenshot or here
• Classpath entries
  • Leveraging the JDT UI (is it possible yet?)
• Tangential Topics
  • What is single root structure? 279360 282512
  • possible selection of basic vs. flexible
  • Allow virtual archive component's runtimePath member var to be used again 276825
  • Allow extension point to turn handle uri's into IVirtualReferences instead of StructureEdit having only 3 types hard-coded 282269
  • Clarifying javadoc for IVirtualComponent.getName() and IVirtualComponent.getDeployedName()
    • suggestion: Deprecate getName(), replace with getId()
    • clarify getDeployedName() should / should not include the extension
  • Excessive complexity in JEE Tools' models and possible solutions 282830
    • Summary: More "references" should be stored in component.xml, not invented by *VirtualComponent or J?EEFlexProjDeployable
    • Virtual Component and Deployable can both be super-thin wrappers, not lose functionality

Minutes

Review the proposed scenarios Rob had to update the link to his screenshot

Rob: We could replace all of the add buttons with one "Add reference" button, with an "Add resource mapping"

Rob: I would prefer that the actual update be done in the wizard from the add button, and not wait for the Apply button

Kostantin: Problems w/ maintaining unmodifiable references

Rob: For the longer term, it would be better if we had some module factory that handled

Konstantin: References in the component.xml are no longer necessary/sufficient... there is now the classpath additions that do some of this - I believe the original intention was to phase out all of these in favor of classpath tags

Rob: I was going to suggest that we open up the ability to create component references out of UI handles- instead of moving everything out of this component.xml, we would be moving everything into it.

Konstantin: There was a very, very specific reason why the classpath tag was adopted- there were a ton of bugs where the classpath tags were getting out of sync w/ the component.xml. We had a lot of complicated code that kept getting broken when those two things got out of sync. Extensible tags came along, and now we just worry about populating the tag and do not need to worry about synchronization. We can't think of the component model as entirely made up of entries in the component.xml.

Rob: Adding the classpath references is not being done in the components, but instead in the deployables. Things are being done in 4 different places- the xml, invented references, in the module, or in the deployable. If we were all to agree, everything would be done in the component.

Chuck: We can look at the component API & make sure anything that is derived is consistent within the component API.

Konstantin: The question is, why was that done in the first place? That was Rob Frost's code- I want to make sure that we don't go back to the problems we used to have with sync.

Rob: We can do everything in the component file, still...

Konstantin: The thorny issue is classpath tags- they're still not a boolean on/off switch. JDT gives you API, but not a UI. We need to be able to manipulate the deploy path associated with classpath entries somewhere. Use cases:

User starts out w/ classpath entries. We need to be able to let them add a reference - an add classpath entry reference

Rob: I understand what you are saying

Konstantin: Two items to do: Adding a reference to a classpath entry and creating a classpath entry with a reference

Chuck: I hadn't thought about changing the deploy path of an entry in the classpath. We need to see everything fully expanded within this view, and perhaps factories to expand references.

Rob: Because of the way they are expanded, we cannot show the full contents here at all. The other thing: If the classpath has 4 jars in it, and you put a reference to the classpath into it, it will list the 4 jars, not the classpath. You can uncheck some of the jars and then press OK, come back again, and you see all 4 are still checked.

Konstantin: This is why last time I attended, I discussed the need for two model layers. The API that we have talks about the expanded state, not the underlying parts. That is what you are seeing there- by the time the UI gets hold of it, you are seeing the resolved entries. We need to edit the raw entries. But we don't have that API yet. Oracle would love to have that API for our publisher- we have to parse the component file ourselves in order to get at those.

Rob: Why haven't you proposed that API extension before?

Konstantin: Because we keep getting cut and cut in size, and there are only so many hours in the day. Going forward, we want to set aside some time to help in this.

Rob: Just to come back to something concrete: What are the use cases right now where people have variables, etc. where people have these items listed in their component.xml.

Chuck: As Konstantin mentioned, these existed before we even contemplated using the classpath metadata.

Konstantin: The use case in question would only be legacy usage. There is no good reason for people to be using these today, but people stumble upon them and then keep using them- so we need to support this for backwards compatibility.

Rob: We need to support having to read these, but we don't need to continue to expose these buttons any more.

Chuck: Let's keep in mind that this is mainly targetted towards the EAR, whereas the classpath discussion is moreso for other modules within the EAR.

Konstantin: I would say that it is wrong to have strict jar references in the EAR. We want to surface the more general assembly within the EAR, not the references.

Chuck: If you abstract out the component file as just a collection of files, and then you...

Jason: One of the strange things in the component is that you can sneak in a reference to a set of jars.

Konstantin: But today, you should be able to do that all with the JDT classpath stuff

Jason: Yes, you can.

Konstantin: Let's talk about EAR. You need module reference. You need resource link. That's it, right?

Rob: Resource link doesn't go outside of the workspace.

Konstantin: We can make resource link more generic so that it works for both. So what I am going to propose is that, instead of working around the VirtualComponent API, we make a new API, and then shim the VirtualComponent API into the new API.

Jason: What would the new API have that the old one doesn't?

Konstantin: The reconciliation of the resource links, a more explicit model for accessing the raw info, it would not have the jar/jee construct pushed into it at such a deep level.

Chuck: It needs to be investiagted- how much of that can be changed w/o breaking API

Rob: I've submitted some bug requests with patches. It doesn't seem that it would be hard to read in the older types, and if it fits to one of these types, then change it and save it.

Jason: We have a requirement that some of the back level workspaces still work- it would be difficult to do that and keep it so that the users can use the same workspace in their old versions.

Konstantin: Set a line where, once a user does one of the new things, it is now a new version only

Chuck: But we need to document where that line is and let users know when they cross that line

Rob: The Server API wants to know what your sub-modules are. That's what complicates the issue the most. You guys look through the project for anything that might be a child module (or otherwise associated).

Chuck: That sounds like something that should only be in the deployable class.

Konstantin:

Rob: It opens every jar, every war, everything looking to see if the resource should be part of the deployment- it seems like a big performance hit.

Jason: Does this happen all of the time?

Rob: Whenever members gets called

Rob: Things are often published as a resource and as a child module. Each publisher seems to handle this differently.

Konstantin: Wouldn't the defacto implementation be the reference one- the default publisher?

Chuck: We're getting off topic- this is moreso the IModule API for deploy

Rob: This adds a lot of complexity to the module factory

Rob: What we want to do is process the old metadata, but not expose lib and var to be created any more

Chuck: So, your existing UI...

Rob: When you remove the var and lib entries, the UI becomes very clean and easy to understand. Right now, the references are just the standard add/remove references from VirtualComponent. But, if we update the buttons to be a more generic add references, the API needs to make sure it can at least tolerate it.

Konstantin: What is the difference between a reference and a resource link?

Jason: I don't think there is one.

Rob: A reference references a virtual component, a resource link references an eclipse-style Resource

Konstantin: If you add in a reference, you still need to add in where it is deployed to. We could simplify the model level down to a map of links with deploy path on one side and a URI on the other. We have several types of those, and off it goes, customized by extenders. I really think we should get back to thinking about this as an assembly view. You are not trying to do any high level reasoning about what you are trying to assemble. You let somebody else worry about that.

Rob: Resources are just weaker dependent modules.

Konstantin: I will take a stab at defining that low-level API.

Chuck: Rob, we do agree on removing those buttons and adding an extensible button.

Rob: Let's look at bug 276825 and see if we can do that in addition to Konstantin's API

Jason: Rob, did you plan on putting in any of your UI improvements yet?

Rob: I can try to create a patch, but I haven't because things are still up in the air.