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