Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

(Content of the Module Dependency Page (Note that this is focused at EAR module assembly))
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Attendees  ==
 
== Attendees  ==
 +
* Carl Anderson
 +
* Chuck Bridgham
 +
* Jason Sholl
 +
* Rob Frost
 +
* Kaloyan Raev
 +
* Angel Vera
  
== <br>Agenda  ==
+
== Agenda  ==
  
==== <br>Proposed Scenarios&nbsp; ====
+
==== Proposed Scenarios  ====
  
 
*Select projects (add/remove)  
 
*Select projects (add/remove)  
Line 10: Line 16:
 
*Editing the deployment path/archive name
 
*Editing the deployment path/archive name
  
====  ====
 
  
 
==== Action Items  ====
 
==== Action Items  ====
 +
* 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 ;))  ====
 
==== Content of the Module Dependency Page (Note that this is focused at EAR module assembly (but shouldn't be ;))  ====
  
 
===== Structure of the Page =====
 
===== Structure of the Page =====
* [http://imagebin.ca/img/LOaeqx6.jpg screenshot]
+
* [http://imagebin.ca/img/LOaeqx6.jpg screenshot] or [http://oxbeef.net/image2/code/jee_status_meeting_20090722.jpg screenshot]
 
* One entry point (Module Dependencies page, ModuleAssemblyRootPage)
 
* 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 has facets (if not, error composite is shown)
Line 54: Line 63:
 
*Leveraging the JDT UI (is it possible yet?)
 
*Leveraging the JDT UI (is it possible yet?)
  
===== <br>Tangential Topics <br> =====
+
===== Tangential Topics =====
* Single Root Structure bugs: [https://bugs.eclipse.org/279360 279360] [https://bugs.eclipse.org/282512 282512] [https://bugs.eclipse.org/284187 284187]
+
* Bugs with patches
** Should single root structure change the result of members()?
+
** getName() vs getDeployedName() (and Allow virtual archive component's runtimePath member var to be used again) [https://bugs.eclipse.org/276825 276825]
** Or should it just serve as a marker to report whether it is or is not in single root format?
+
** Allow extension point to turn handle uri's into IVirtualReferences instead of StructureEdit having only 3 types hard-coded [https://bugs.eclipse.org/282269 282269]  
*possible selection of basic vs. flexible
+
** page's subclass could listen to proposed changes and change message if item is now 'complex'
+
*Allow virtual archive component's runtimePath member var to be used again [https://bugs.eclipse.org/276825 276825] - Any progress here?
+
*Allow extension point to turn handle uri's into IVirtualReferences instead of StructureEdit having only 3 types hard-coded [https://bugs.eclipse.org/282269 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 [https://bugs.eclipse.org/282830 282830]
+
**Summary: More "references" should be stored in component.xml, not invented by *VirtualComponent or J?EEFlexProjDeployable [https://bugs.eclipse.org/282515 282515]
+
**Virtual Component and Deployable can both be super-thin wrappers, not lose functionality
+
  
== <br>Minutes  ==
+
* Other
 +
** Single Root Structure bugs: [https://bugs.eclipse.org/279360 279360] [https://bugs.eclipse.org/282512 282512] [https://bugs.eclipse.org/284187 284187] [https://bugs.eclipse.org/249044 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 [https://bugs.eclipse.org/282830 282830]
 +
***Summary: More "references" should be stored in component.xml, not invented by *VirtualComponent or J?EEFlexProjDeployable [https://bugs.eclipse.org/282515 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  ==
 +
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

Latest revision as of 05:57, 29 July 2009

Attendees

  • Carl Anderson
  • Chuck Bridgham
  • Jason Sholl
  • Rob Frost
  • 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

  • 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)
  • 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

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

Back to the top