Max Rydahl Andersen wrote:
Rob - this specific feature were spec'ed out to be so it worked
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
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