[jbosstools-dev] Current WTP-style project offerings

[Rob Stryker]

Max Rydahl Andersen wrote:
> 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.

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.

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.

If the BPEL facet does provide some functionality and should be able to 
be enabled on other projects, then that means we'd need a second facet 
for the BPEL project to alert the module factory that this project 
should be exposed.   However I don't feel I can make any of these 
decisions since I am not familiar with the bpel plugins, their code, or 
what functionality it is they provide and where.

I have a patch that can make a bpel project with only the bpel facet, an 
output folders mapping, and a bpelContent folder (also mapped), but like 
I said this patch is virtually worthless other than as a proof of 
concept because without having a discussion related to the above points, 
I don't know which course of action to take, whether to add a second 
facet for deployment, or how to have the module factory know which 
projects it should expose.


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.

Just a thought.