Re: [jbosstools-dev] The issue of project module factories

Firstly I don't know which specific Project Explorer view "Navigator Content" you're talking about. Here are some to choose from: JEE Navigator Content Application Client JEE Navigator Content EAR JEE Navigator Content EJB JEE Navigator Content WEB J2EE Application Client Deployment Descriptor J2EE Connector Client Deployment Descriptor J2EE Application Deployment Descriptor J2EE EJB Deployment Descriptors J2EE Web Deployment Descriptors JPA Content

While I can't say for sure, I would be hard pressed to imagine that the "Deployment descriptor" content extension would *ever* be accessing the servertools API. I'd imagine these navigator content objects would instead be accessing the API's to read the deployment descriptor and not giving a damn at all about what the servertools API said. The "Deployment descriptor" entries probably wouldn't even care about the virtual component at all. Also looking at for example the "JEE Navigator Content EAR" content provider (Ear5ContentProvider) it simply accesses the VirtualComponent directly rather than the module factory. Since the module factory is a (bad) wrapper around the virtual component, this seems ok. However, I also see problems I don't like in the EarVirtualComponent (and other) type classes. Primarily, they actually refer to jar libs inside the lib folder as a "reference" even though CLEARLY it's NOT a reference... However changing their virtual component could have much more widespread effects than changing their servertools wrapper of it and so I wouldn't consider changing their VC any time this year. Anyway the issue here isn't about changing the existing ones inside WTP but deciding what framework *we* should use for OUR cases to cover all use-cases. Since the Project Explorer (and even the server view, now) are based on Common Navigator, we can *always* add our own extensions to it to display whatever content we want. Since WTP seems to add about 10 pieces of content to the project explorer (and none of those 10 would work for our ESB content since their extensions ensure that the project has, for example, the ear 5.0 facet), adding our own ESB content or ESB Descriptor content would fit right in with what they're doing and indeed be completely necessary anyway.