Bugzilla – Full Text Bug Listing
| Summary: | non-binary used references are not returned from FlatVirtualComponent | ||
|---|---|---|---|
| Product: | [WebTools] WTP Common Tools | Reporter: | Jason Peterson <jasonpet> |
| Component: | wst.common | Assignee: | Rob Stryker <stryker> |
| Status: | RESOLVED INVALID | QA Contact: | Konstantin Komissarchik <konstantin> |
| Severity: | normal | ||
| Priority: | P3 | CC: | ccc |
| Version: | unspecified | ||
| Target Milestone: | 3.2 M6 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
I think I'm going to disagree and vote that this bug is invalid sadly ;)
>> However, clients should not have to override the isChildModule call to get
>> these references. By default, it should create an IChildModualReference or
>> similar type that would store the referencedcomponent for each.
If it is not a child module, it should not be exposed as a child module via a child reference of any sort. You will note that the only caller of addUsedReference(etc) is addUsedReferences(etc), and that addUsedReferences(etc) *specifically* checks if this is a child module or not ;) That's the design. I can change the method name to be a bit more clear that it's only handling non-child module references.
The publish code currently uses a participant specifically for this purpose: JEEHeirarchyExportParticipant. This is the participant that says which references are child modules and which are not. It also says which regular files inside the project are child modules and which are not. In fact, I would suggest export use the exact same participant. This is part of the design of the API. The participants get to decide what they want to expose as children and what they want to expose as resources.
- A bit of musing below, on a related topic -
The fact is that two out of four of the possible combinations (used / consumed, child / non-child) are very confusing and not intuitive.
So let's set up an example here. Let's give us an EAR project (eProj), and an unknown-type modulecore project (uProj).
Let's assume the EAR has an empty folder EarContent, and a project reference to uProj (with archiveName=uProj.jar)
Let's assume the Unknown project has a mapped folder UnknownContent, with a text file "unknown.text" inside it. So our workspace looks mostly like this:
eProj/
eProj/EarContent
uProj/
uProj/UnknownContent
uProj/UnknownContent/unknown.text
Case: 1) CHILD MODULE, with reference type USED
---
eProj.ear
eProj.ear/uProj.jar (CHILD MODULE)
eProj.ear/uProj.jar/unknown.text (member resource of child module)
Case: 2) NOT child, with reference CONSUMES (fairly simple)
---
eProj.ear
eProj.ear/unknown.text (consuming directly, member resource)
Case: 3) NOT child, with reference USES
---
eProj.ear/
eProj.ear/uProj.jar (MEMBER RESOURCE / folder, and thus confusing)
eProj.ear/uProj.jar/unknown.txt (MEMBER RESOURCE)
Case: 4) CHILD with reference CONSUMES
---
eProj.ear/
eProj.ear/unknown.txt (unknown.txt is the child module??, clearly not! very confusing).
So as we can see, USING a non-childModule, or CONSUMING a child module, are both very very odd scenerios that really at this point need further discussion. Because your list of participants is not designating what's a child and what isn't, your situation is being mistaken for using a non-childModule.
But I'll finish this up by saying that the block of code you're pointing to is NON-child modules with a used reference, which is case 3 and one of the confusing cases. It cannot be exposed as a child module reference because the heirarchy / list of participants you have specifically says it is not a child module.... so I suggest you use the JEEHeirarchyExportParticipant ;)
This is working 100% as designed for now.
|
Currently, by default the non-binary used references are not saved by the FlatVirtualComponent. Here is a snippet of the code in the FlatVirtualComponent.AddUsedReferences(...): if( virtualComp.isBinary()) { . . . } else /* !virtualComp.isBinary() */ { /* * used references to non-binary components that are NOT child modules. * These should be 'consumed' but maintain their name * As of now I don't believe there are any such instances of this and this can be delayed * I also believe in most cases, this probably is a child module that the parent just doesn't know about. * Example: Ear Project consumes ESB project, Ear project does not recognize ESB project * * TODO Investigate / Discuss */ } The current deploy code doesn't lose the non-binary used refs because it overrides the isChildModule(IVirtualReference referencedComponent) call which handles these type of references. However, clients should not have to override the isChildModule call to get these references. By default, it should create an IChildModualReference or similar type that would store the referencedcomponent for each. Clients could then use the FlatVirtualComponent on the saved components to get the resources.