[jbosstools-dev] The issue of project module factories

[Max Rydahl Andersen]

Rob Stryker wrote:
> 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
Any of the above...
> 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.
The only reasons I can think of for scanning jars inside the content 
folder is that it shows up in the server view ui as things that you can 
do operations on (start/stop/etc.), or is that something else than child 
modules ?

If that isn't relevant for stuff inside the content folder and you can 
100% clearly identify which folders/resources not to scan then I don't 
see a problem with it...and it is easier to add this scanning back in 
than to take it out I would imagine ?

/max