JEE Status Meetings/2009-07-23
- Carl Anderson
- Chuck Bridgham
- Jason Sholl
- Rob Frost
- Kaloyan Raev
- Angel Vera
- 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
- Rob: attach a patch
- Committers: review Rob's already attached patches
- single root validator - WTP 3.2 M2 ?
- Chuck- open a bug for the output mapping issue - bug 104597
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)
- 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)
- 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
- External jars
- Workspace Jars
- The code in these reference types has not been coppied from AddModulestoEARPropertiesPage
- Contains a two column viewer, and some buttons
- Leveraging the JDT UI (is it possible yet?)
- Bugs with patches
- 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)?
- Single Root Structure bugs: 279360 282512 284187 249044
Carl - intro
Rob: Talked through the UI changes as seen in the agenda The entry point to the page is the same as the current one- users of their own project can override it and add controls We can make it look as much like the current Java EE Module Dependencies page as we want
Carl: in past discussions, we had decided to move the change library functionality off of this page
Rob: We can use the API and get a list of resource mappings
Jason: These are just pulled from the .component file, right?
Rob: Yes, these are just the wb_resource tags
Chuck: The wording confused me at first- can we get better wording?
Jason: I would call it add folder
Rob: Add folder would work. Perhaps we should rename the page to Module Assembly?
Carl: We had talked about that in the past- Module Assembly is fine.
Rob: I would have to use the EMF model to get to the resource mappings
Chuck: Should we consider exposing some of that as API?
Rob: The current API just uses get root folder and handles it. Maybe it should be exposed, maybe not.
Chuck: The component core is supposed to be the virtual file system... there still may be a need for additional API, even if it is internal, at the StructureEdit level
Rob: for the earliest release, we want to get something working and usable. Right now, i have one extension point w/ 4 implementers Someone could define their own extension w/ their own component None of the underlying logic of how they deploy has been touched The UI is solid and ready to go. The rest is just the underlying parts- they need to be tweaked to do what they are supposed to do
Jason: Can we have a patch?
discussion about what plugin to create/add it to.
Rob: One other thing I wanted to discuss- EARVirtualComponent still returns things as references that are not actually
references For instance, the JEE classpath references are returned
Chuck: Maybe we should have a notion of derived references that are never persisted... especially since we are passing around
a collection that could be passed back and then persisted.
Rob: Would we be modifying the virtual component interface?
Jason: We would be adding a field to IVirtualReference to mark if it is derived Also, since this page is really just modifying the StructureEdit, perhaps we should be going straight to the StructureEdit
Chuck: Not sure- I think the users want to see what is deployed from here. We're introduciong the concept of resource mappings- if you have content that is not in the default resource mappings, it wouldn't be published either
Rob: it is assumed that any of the content of your ear would be published. Once you show that the ear content is mapped, the rest should be obvious. Derived classpaths are a very curious situation
Jason: If you don't tread derived modules as references, you can't get to them One of the things we might be able to do is to filter out the references like that by their source location If their source location is already in the mapping, we could filter them out
Rob: Who uses the getReferences? Could EARVirtualComponent have its own method?
Chuck: Yes. Have a getReferences(), and then a getAllReferences()
Jason: Let's pass in a flag. That would be a good universal solution
Rob: The key would be to get the module factories to use it appropriately. But this would work great for the UI I would still like to see one persisted entry that resolves to the classpath entry
Chuck: If that entry didn't exist, then we would know we didn't have any classpath entries to bother with
Rob: It would be there by default.
Jason: Right now, it is effectively there as a default.
Rob: If it isn't set, it would still be there. It would just return a reference to no jars. If they go and start setting classpath folders and classpath containers with that flag, that reference starts returning more and more.
Jason: In this page, would we remove all of the classpath stuff? Would the user have to go and manipulate the classpath instead?
Chuck: We never did resolve that. That is a place where it would be great to let the JDT do their thing.
Rob: The rest is just the list of bugs that we need to get working on getName vs. getDeployName 276825
Jason: Let's deprecate them both and then force consumers to move away from them The deploy path solves all of that - the name would just be the last segment
Rob: Not everything has a deploy path getDeployName can be overwritten in the component file- but there is no standard- should it return a name with a suffix?
Chuck: I would like to avoid deprecating as much as possible- it confuses people
Jason: What is the point of getName?
Rob: If you have an ear & give it a different deploy name, getName returns the project name, getDeployName returns what it will be called when it is deployed It just needs to be javadoc-ed and needs to state that the deploy name needs the suffix, the getName needs the suffix, both
should only be a one segment file name
Carl: I am adding an action item to review Rob's patches
Discussion of bug 282269
Discussion of single root structure
Jason: Could we put a property in the component file for this?
Rob: Part of the problem is incorrect identification of single root structure
Jason: isSingleRoot() should be a flag, and shouldn't modify what is returned Perhaps a validator or somesuch that displays this to the user?
Angel: Why is the validator even validating? What would it force?
Jason: The validator would just validate
Carl: The validator just displays to the user whether or not the validator is happy, and if not, why not
Jason: The validator then sets the flag in the component file, which the server adapter can then query
Angel: I am not sure why that flag matters to the server adapter
Rob: One of the other things I noticed in these mappings, if you create a new web project, it adds a mapping to the source directory, but when it tries to expose it, it has to get to the binary - the build output.
Chuck: That's an old bug. We'll have to look at it again. We'll have to do special casing for the deploy
Rob: I found some interesting problems- for instance, two source dirs going to one output, but only one source dir is mapped, the output from both get pulled in. What is the feasibility of having this sort of thing fixed?
Jason: I would say it is not feasible.
Chuck: I wouldn't go that far. But this would be yet another migration of the component file that would have to occur.
Jason: Don't users think in terms of source folders? I think that is part of the reason why we originally did that. One of the most common things we do is- get the source folder, where does it go out to? OK, map that.
Rob: If this was a hybrid resource mapping that Konstantine talked about, then this could perhaps be done.
Jason: It already does that, it just doesn't give the user control to not do that.
Rob: I guess that one will need more discussion On the other hand, the module dependencies page- if you show 3 source folders, would the user be confused if they have to map their output instead of their source? If they see that webcontent is mapped to root and binary is mapped to WEB-INF/classes, it should be apparent to the user what
they need to do.
Chuck: Let me dig up some of the old bugs, retarget them, and look at them again.
Jason: I tend to go the other way- if the user is dealing with the source, why would he want to deal with anything else?
Rob: What if the user wants to deploy both the source and the binaries? The current situation, the user is forbidden from mapping the source in, even if he wants to.
Jason: Maybe we could figure out a way to get a little bit of both. By default, it works the way that it does today, but the user could do something to do what you want. It would be confusing for the user to have to map both the source and binary when they create a new source folder.
More discussion of single root - cleanup, validator targetted for WTP 3.2 M2