Skip to main content
Jump to: navigation, search

JEE Status Meetings/2009-07-23

< JEE Status Meetings
Revision as of 17:20, 22 July 2009 by (Talk | contribs) (Tangential Topics)



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

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

Structure of the Page
  • 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)?


Back to the top