JEE Status Meetings/2009-07-30

Attendees

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

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

• Everyone: Review Rob's patch at 277482
• 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

New:

• 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

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: we should move the JavaProjectMigration classes down to a common JST plugin

Jason: I want to get this into 3.2 as soon as we can to start addressing the bugs in it

Chuck: little things, like if you start adding references, it still shows all of the references in the dialog

Rob: yes it should always filter out itself

Chuck: as well as filtering out existing references

Jason: I am sure we will find more bugs as we keep using this

Chuck: do we want to keep it as a separate property sheet while we work these bugs out?

Carl: we still have to deal with handling the EAR lib

Rob: 284044 - basically, it ignores being able to set an archive name It specifically checks to see if you are a utility module, and doesn't let other things through There might have been an intention behind it. All of the other ones have to be blatantly listed in the descriptor.

Chuck: OK, it is agreed that, for now while we are working through these issues, let's keep both I am OK with putting this in as is

Jason: we need to do a little clean up - if this is going into WST, we need to remove some of the JST references

Chuck: it will be tough to put this into WST, then- due to the jar references

Rob: we could move the three classes that have JDT references into extension points

Carl: perhaps move it down to the jst.common.framework level? does it make sense to have a page w/o the jar references?

Rob: yes. Project references would still work

Jason: there is also a call to jem.util there. We are working on refactoring that out of wst

Carl will work w/ Rob to remove that prereq

Discussion about the various plugin names and package names and consistency

Rob: the figment references - even if you remove them, they don't get removed, because they aren't really there. We really need the derived reference API

Jason: what if we coded this straight to StructureEdit?

Chuck: I sort of agree with that- we may need API to get at the StructureEdit, but ComponentCore may not be the best place to put that API.

Jason: the StructureEdit is a direct reference to the .component file that we are discussing. The Component layer adds in the derived references and all of that on top of the StructureEdit. I believe that it is implemented the way that it is because the Component layer adds in the updating of the deployment descriptor and all of that, which the StructureEdit doesn't do

Rob: Already, this page basically does just edit the StructureEdit, it just does it through a DataModelProvider

Jason: but what about for reading?

Rob: For reading, there is no easy way to gain access to all of that

Chuck: so basically, you just drill down to the StructureEdit to get all of that information, right?

Jason: if you just called the VirtualComponent.getReferences() instead of the subclass's implementation, you would get what you need

Carl: there's no way in Java to bypass the subclass's implementation

Rob: Make getReferences() only return what is in the component file, and then add in another API to get all the references

Carl: we discussed adding a getReferences() with a flag, to get only the component references if desired

Rob: right now, I have all of the EAR stuff commented out - it is possible we don't need to fix the archive path bug, since we are not using the EAR-specific DataModelProvider

Carl: we need to run the current code through its paces to make sure it does what we need it to do

Rob: the question is, what do we want it to do?

Jason: it should update the application.xml if there is one, otherwise do just what it does today.

Rob: then we do need to subclass

Chuck: We do

Jason: if that is the case, maybe this generic properties page just needs to be subclassed, and then shown slightly differently for the EAR case

Rob: right now, it is commented out. You can add that back in. So basically, we need one plugin for the core, another for the JDT/JST UI, and put the EAR stuff in j2ee.ui

Jason: yes, j2ee.ui. If we subclass for the other module types, that would also go in j2ee.ui

Carl: the one oddball might be web - we are still structured to pull things out for web, but we don't need to worry about that right now

Discussion of action items

bug 104597

Rob: We need to have the module factories start dealing with the binary directories instead of the source directories

Chuck: We'll see what we uncover when we do that