[jbosstools-dev] [Fwd: Strategy regarding Module Factories, Virtual Components, and future project structure]

[Max Rydahl Andersen]

Here is a mail outlining the module factory changes we are looking at in 
JBoss Tools (written by rob):

So after connecting with Max at JBossWorld and demonstrating some of the
code and APIs that are available to us, we've got a strategy for what
our projects should look like, and how this should *not* hurt our
long-term strategy of keeping the projects easy to use, configurable in
one place, and overall clean and solid for everyone.

We *will* be making as many of our projects as possible be "Webtools"
projects. The key thing that makes this possible without complicating
everything is the new reference resolver API which I'm trying to get
into WTP, but which we have a version of right now.
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=282269)

The interesting thing is the component.xml, which links project types
together, has a "dependency" tag, which means you can say the ear should
have the war inside it. This is well and good, but the dependency tag
has *two* dependency TYPES.  The first is "uses", and that's where it
would end up something like some.ear/inner.war/all/the/files.   However
the second type is "consumes" and what consumes does is basically
pretend anything inside this second project (or component, which is not
limited to projects) would be injected directly into the ear as if it
was part of that project. Basically, what this does is just ignore the
inner component's name, and what you'd get is something like
some.ear/all/the/files.

Now, why this is absolutely awesome is that with the API addition that's
coming, we can create references based on whatever we want, whenever we
want. There have been many many longstanding bugs in WTP from people who
want to embed a java project, but do *not* want that java project to be
forced to become a WTP project. Using the new add-reference wizard, we
have the ability to make *anything* consumable; anything that we want.
Plain java projects, anything.

I don't have all the code committed yet, but today I played around a
*lot* with the possibilities and with a few classes, I managed to add
this to an ESB project's component.xml using the standard wizard which
will be in WTP:

<dependent-module deploy-path="/"
handle="module:/org.jboss.ide.eclipse.as.wtp.core.vcf.outputFolder/ESBPro">
   <dependency-type>consumes</dependency-type>
</dependent-module>

The key part to look at is the handle, which I get to resolve. I take
that handle and add turn that into a Virtual Component of my own, one
which returns *only* the resolved and mapped resources inside the ESBPro
project. I could also make one to return an IVirtualComponent based on a
plain old java project if we wanted... or a classpath container, or
*all* exported classpath containers, or whatever I want. This clearly
opens many doors for the user, and it means that this new flexible
structure should definitely be our direction.

Most of the code is already committed but if you use it today or
tomorrow you'll notice it doesn't "finish" by actually publishing the
source.
That's because I spent a lot of the time working on the infrastructure
and still need to make a few utility classes to help with the last part.
But the way is made clear and this is pretty solidly awesome. I'm not
sure if I'm being linguistically adept enough right now, so if there are
any questions feel free to ask.