Re: [jbosstools-dev] Current WTP-style project offerings
> 1) IMO we have no backwards compability requirements here since
we
> should be moving these jboss specific facet/deployment behavior to a
> separate plugin/set of id's. i.e. if you use the org.eclipse plugins
> you just keep doing that and it will still work, correct ?
> Furthermore we moved to use utility jar so that is what will deploy
> for the old ones, not ours...afaik (please verify that ;)
I have no idea what to do now honestly. I don't know our strategy
with the bpel plugins. I don't know if I should be making new
differently-id'd facets. For example currently our forked facet
installation delegate for bpel was last modified by denny, but it's
clearly in a package and project named org.eclipse.bpel.etc.
yes, which were ok
since the wizard just created one being driven by
utility jar. i.e. these projects will continue to work since no bpel
stuff in them.
Not to mention I'd be hesitant to change the facet ID we use in
our
projects because who knows what other blocks of code use
"bpel.facet.core" hard-coded as a string throughout the code. Aside
from that, if we switch to a different one, users may than have
multiple BPEL facets, one from eclipse and one from us, and I'm not
prepared to make that decision since this is not my area of code.
As discussed
later today - we just remove the deployment/runtime part of
eclipse bpel tooling since its broken anyway.
So far we have only one bpel facet in our installation, and it is
required in the bpel project, but it can also be added to other
projects. Because of this, we can't make the bpel facet conflict with
modules, but we also don't want the bpel module factory exposing a Web
Project which has BPEL facet enabled because the web deployment
factory will already handle that case. I'm not sure what, if any, the
bpel facet actually provides, so I don't know whether it's a good idea
to mark the facet as conflicting with the modules group.
Is this still an issue ?
won't the content folder be different for the
two aspects ? i.e. war and bpel would pick up from different folders or
how ?
How does the virtual component actually work here ? does it have two
separate components.xml or how ?
An alternative, Max, which you had mentioned before, is that I could
just make a generic deployment factory (ie only one class instead of
several subclasses) and so long as the project has a flag on it, and
is a module core project, I can have this one factory expose it. Then
all we'd need to do is set the flag on the bpel project and sidestep
these issues.
Does that make sense for all module core projects ?
/max