[jbosstools-dev] The issue of project module factories

[Rob Stryker]

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.



Max Rydahl Andersen wrote:
> So this does not influence what you can see in the Project Explorer 
> where it shows JEE artifacts ?
>
> -max
>
> Rob Stryker wrote:
>> An alternative idea is that I could expose anything in the 
>> component.xml file as a child module, and anything specifically 
>> placed inside the project as a resource...  This would be even 
>> easier, but could be less accurate if someone links / embeds an 
>> out-of-workspace jar that's not a module of any sort but I'm listing 
>> it as one.
>>
>> Rob Stryker wrote:
>>> This is a short discussion regarding project module factories for 
>>> use while investigating how to implement the esb module factory 
>>> properly:
>>>
>>> Most of the module factories in eclipse are excessively inefficient 
>>> (and complex). The server API doesn't *need* to be that complex. 
>>> Some of the reasons for this are that the virtual component 
>>> framework has references to other projects, references to outside or 
>>> inside jars, and references to classpath variables. This in itself 
>>> isn't hte problem... the problem, ultimately, is that for each 
>>> resource (inside hte project or outside), the factory needs to 
>>> decide whether this is a "resource" to be published, or a "child 
>>> module". It then also needs to create a child module wrapper for 
>>> each of these jars that count as child modules.
>>>
>>> The way most of hte module factories out there do this is by OPENING 
>>> and SCANNING each jar / zip resource in the project and checking for 
>>> certain descriptors to find out if this is an approved module or 
>>> not. If it's an approved child module, it comes up as a child 
>>> module. If it's not, it comes up as a resource. As we've seen, 
>>> though, there were for a long time bugs where something would come 
>>> up as both.
>>>
>>> It's arguable that, if we simply treat ALL jars (inside the project 
>>> or linked) as "resources" instead of child modules, this removes the 
>>> necessity of scanning each file, opening it, etc. This also means 
>>> the only thing that would qualify as a child module would be linked 
>>> projects.
>>>
>>> So... what do we lose by this?  What functionality do we lose by 
>>> treating these jars as resources and not as child modules?
>>>
>>> As far as I can tell, *all* we lose is UI... the ability for the 
>>> child module to show itself properly in the view as a child module, 
>>> or in the add / remove project wizard.  I'm still investigating of 
>>> course, but I believe that if we were willing to take this UI hit, 
>>> the programming of a proper deployable factory for ESB (and all 
>>> other new) project types could be much cleaner, much more efficient, 
>>> much more maintainable, and much less controversial than the 
>>> JEEModuleFactory.
>>>
>>> Thoughts?
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev 
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev