6:19 a.m.
I had a chat with Rob yesterday walking through some of the code
concerning this issue of ESB modulefactory.
The problem is that ESB modulefactory is very incomplete, fragile and
does not fit well into the rest of the WTP projects.
Most of this is caused by the non-correct usage of virtual component
model (VCM). (the code related to this is here:
http://fisheye.jboss.org/browse/~raw,r=13591/JBossTools/trunk/esb/plugins...)
There are also other weird things in this code, like the 'if more than
one VCM folder pick the 2nd, otherwise use the 1st" - that will break
any attempt by users
to have separate folders for various content.
Anyhow the broken usage of VCM needs to be fixed if we want to have ESB
projects to be usable in context of the JEE module dependencies page
which we want since that will allow us to embed ESB's inside EAR's and
more importantly allow users to have the ESB archive depend on
multiple/other projects in the users workspace - i.e. if he has the
model in projectA and the rules in projectB then an ESB project can with
proper usage of VCM use JEE module dependencies page to declare a
dependency on projectA and projectB and specify how it gets packaged.
What I asked Rob to do is to create a base module factory class which
uses VCM cleanly and then for the ESB subclass we can reuse the old (but
broken) modulefactory code for old ESB projects and for new ESB
projects. To distinguish between the project versions rob will add a
property to the project so the modulefactory can handle both.
We should also look into having a quickfix for fixing the broken esb v1
projects to v2 in case users want to get the advantages of the fixes above.
Note, most of this is currently just under the covers and not exposed to
users, but when/if we get the fixes into WTP that rob helped on the last
months then
this will become visible to users and we will finally have a WTP that
actually works when it comes to multi-part-projects.
/max
Rob Stryker wrote:
Max Rydahl Andersen wrote:
> Rob - this specific feature were spec'ed out to be so it worked as
> WTP does it so we would be sure it would work (equally bad/well). If
> that was not done then its up to the dev(s) working on it to speak up
> and say "heeey! This won't work!". That have happend on occasion and
> then we have pulled it from a release. If you think stuff is missing,
> then speak up - but be specific (as you are in this email)
We cloned the WTP structure but never completed a module factory for
any of our projects yet, at least not a real one. We can't extend
their jee module factories because they're way complex and many parts
don't apply to us. Fact is we *can't* use their module factories as
their module factories simply refuse to turn our projects into
modules. Basically, our ESB project has had a tiny shell of a module
factory and our BPEL one is just really really weird.
It doesn't have to do with the structure, either. It's just that their
module factories check specifically for JEE facets and refuse to
handle projects that are not JEE projects.
> you are saying remove the old line and add in the new one! Will both
> lines work in WTP today ?
Yes I'm saying remove the old line and add the new one in the ESB
project. However, today, none of our module factories even look at the
virtual component model. It's basically 100% irrelevent. The BPEL
project is not a modulecore project, and the ESB project's module
factory 100% ignores the virtual component and doesn't traverse it
pretty much at all.
> i.e. is it just a matter of changing the new XYZ wizard and then the
> new projects will be better and the old one continues to work ?
What I'm trying to say here is that, the current ones (module
factories) *doesnt* work ;) It basically 100% ignore the component
xml file or uses it 100% incorrectly. For example, the current esb
module factory checks for one (ONLY ONE) wb-resource mapping tag. If
it finds 2 (because, perhaps, the user wants 2), the code simply
ignores the second mapping, and takes the first.
Then, rather than traversing that IVirtualFolder, the factory gets the
underlying IContainer object, and just scans that folder... completely
ignoring the point of using the virtual component model.
> Or are you saying lets stop supporting the old lines in
> components.xml, meaning our projects won't work with any
> modulefactories/server adapters than ours ?
First and foremost, we can't use WTP's module factories. Their
factories refuse to look at our project bc we're not JEE projects.
Secondly, the module factory is what takes a project (or other module)
and turns it into the servertools API so server adapters can consume
it and publish it. I'm not suggesting making our projects
unconsumable. All server types who want to will be able to consume
what we give them. That will not change.
I'd also like to note that I am not suggesting changing dynamic web
projects or ejb projects at this time. I am talking only about our
project types for which we control the module factory. If we control
the mod-factory, and we control the project, we can decide how we want
to use our components.xml file. But I am also not suggesting any
radical changes here.
What I am suggesting is to change how we interpret the "old lines".
If a components.xml file says map Project/src to WEB-INF/classes, I'm
suggesting we interpret that 100% literally... and we put .java files
inside their WEB-INF/classes folder.
What this means, though, is that old projects which map Project/src to
WEB-INF/classes (rather than mapping Project/bin to WEB-INF/classes)
would need to be changed, either automatically by us or by the user
themselves in that new mapping UI i've been making. It also means we'd
need to make the default mapping be from bin rather than from src, if
that makes sense.
> i.e. as far as I understand what you are suggesting doesn't break
> anything (just changes how new projects are defined), but you write
> as if it will break stuff ?
Yes... what would break is old projects would need to make a quick
change and stop mapping src to / and change it to mapping bin to /.
Otherwise they'll end up with java files (src) in their .esb output
file root rather than .class files. Make sense? We'd still need to fix
their project for them, or them for themselves, but the fix would be
really really easy in the mapping UI. Just remove the src mapping and
add the bin mapping.