Difference between revisions of "JEE Status Meetings/2009-08-06"

Latest revision as of 11:58, 6 August 2009

Attendees

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

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

Action Items

• Committers: review Rob's already attached patches
  • 276825
  • 282269
• single root validator - WTP 3.2 M2 ?
• Chuck- bug for the output mapping issue - bug 104597
• Chuck will open a bug to move the JavaProjectMigration classes down to a common JST plugin
• Carl will work w/ Rob to remove the jem.util dependency
• Rob will work to refactor the plugins to move the JST/JDT stuff out of WST, and add in stuff for EAR into j2ee.ui
• Carl - work on the derived reference API

New:

• Carl & Chuck will commit the latest patch to 277482 tonight
• Carl will open enhancements to get the Web project properties moved on top of Rob's work

Content of the Module Dependency Page (Note that this is focused at EAR module assembly (but shouldn't be ;))

Structure of the Page

• screenshot or screenshot
• One entry point (Module Dependencies page, ModuleAssemblyRootPage)
  • root page checks if the project has facets (if not, error composite is shown)
  • root page checks if the project can be converted to a virtual component (if not, error composite is shown)
  • root page checks for an extension point (moduleDependencyPropertyPage ) that accepts this project
    • If it finds one, that extension point can provide an array of controls
    • This works very similar to how J2EEPropertiesPage works, but expanded via extension point to more types
    • This is not the suggested use case, but it's provided in case a project type really wants to provide several controls / tabs
  • If it does not find an extension point for this project, it uses AddModuleDependenciesPropertiesPage
    • Project types can use the extension point and just subclass this page, overriding key methods if they want
    • In the screenshot above, the addButtons() has been overridden and the "Change Library Directory..." button has been added. (This is as an example. We can discuss whether it belongs there)
• AddModuleDependenciesPropertiesPage
  • Contains a two column viewer, and some buttons
    • viewer's right column shows the source of the entry / reference
    • viewer's left column shows the suggested deploy-path / archive-name for the reference
      • This can be edited by the user
      • This would be persisted in the component.xml via the archive-name attribute
      • This is currently buggy due to underlying EAR-oriented operations 280416 but using the standard CreateReferenceComponentsDataModelProvider works fine
    • viewer can currently only display IVirtualComponent objects
    • viewer would like to display wb-resource mappings but cannot 284060 - lacks API)
  • Buttons
    • Add Resource Mapping... (currently unimplemented due to API concerns of displaying mappings in viewer)
    • Add Reference...
      • "Add Reference..." opens a multi-page wizard dialog
      • This dialog is based on the wst.server's TaskModelDialog class
      • An extension point (referenceWizardFragment) is provided to create new arbitrary reference types
      • Currently there are four uses of this extension point
        • Projects
        • External jars
        • Workspace Jars
        • Variables
      • The code in these reference types has not been coppied from AddModulestoEARPropertiesPage

Classpath entries

• Leveraging the JDT UI (is it possible yet?)

Tangential Topics

• Bugs with patches
  • getName() vs getDeployedName() (and 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

• Other
  • Single Root Structure bugs: 279360 282512 284187 249044
    • Should single root structure change the result of members()?
    • Or should it just serve as a marker to report whether it is or is not in single root format?
  • possible selection of basic vs. flexible
    • page's subclass could listen to proposed changes and change message to warning if item is now 'complex'
  • 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 282515
    • Virtual Component and Deployable can both be super-thin wrappers, not lose functionality
  • resource mappings
    • Should wb-resource mappings map src to WEB-INF/classes as is done currently?
    • Or would it make more sense to map bin to WEB-INF/classes (simplifying components and module factories)?

Minutes

Chuck commented on the bug - Let's get it in!!!

Carl will check w/ David W about getting it into M1

Chuck: Should we mark this as experimental? Add some text?

Jason: We could change the text on the tree node to add "experimental" and add "This is experimental. Use at your own risk" in the title

Chuck: I have been playing around with it- it is solid. Haven't found any major bugs. But did have to clean up a couple unused imports

Carl: David W wants us to wait until after M1 to do this

Chuck: Can we prove to him that we won't break the build with this?

Jason: The two plugins are added in. If we can prove that we won't break the build, let's put it in. If we have to, let's pull it.

Chuck: The major concern is that we do not break the build. If we can't get it working properly by tomorrow, we will pull it.

Carl: I'll put it in tonight, then.

Chuck: We also need to do the API work we had discussed earlier and then get the existing pages refactored on top of this. We want to get away from the separate tabs and have the table itself designate which deployable case it would be for the references. Do we want to extend the functionality for adding the references? Or do we just want to extend the base case for choosing the deployment path?

Rob: What kind of functionality would you want to see?

Chuck: with the tabs, each tab had its default functionality for the deploy path

Jason: Because this new page is a way to interact with the component file directly, maybe we do want to have two tabs. Moving forward, especially when we start to consider the EE 6 scenarios- there are some cases where you want to consume the jar, other cases where you want to reference it by the manifest. I am not sure that the page that we have today is the best way to show those dependencies. If the base page does both, it may get confusing- when is the base page going to act one way versus another, and what would be the deciding factor?

Chuck: I like the simplification of the one table, with the different types listed. With only two columns, how do we demonstrate what type of reference it is?

Jason: I think we decided that we would do the manifest case with a different action. When we brought up the reference dialog, it would have a different choice the user would select.

Rob: It wouldn't be hard to add a separate tab. However, I like the current tab the way it is.

Chuck: If you want a project to be put on the manifest and be picked up that way instead of jarred...

Rob: Well, that wouldn't be module assembly.

Chuck: Does it show the references?

Rob: That's why we want the other API to not include the references.

Chuck: Then we would need an additional page to show those references.

Jason: Multiple tabs- one Module Assembly, the other Module references.

Rob: I would argue that that would be an extension. It shouldn't be part of the default page.

Chuck: Even something that is part of the Java manifest entry- that could be something that is part of the JST. Not necessarily EE specific, but it doesn't belong in the WST part.

Jason: Perhaps we still have the Java EE Module Dependencies tab. It could be built off of what Rob has done.

Rob: Folders- long term, we need a way to include all of the contents of a container.

Chuck: The intent of the API is to provide a way to aggregate from different sources, different locations.