[jbosstools-dev] Current WTP-style project offerings

[Max Rydahl Andersen]

>> 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