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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev