[jbosstools-dev] Design Question: WTP Facets

[Max Rydahl Andersen]

On Jan 10, 2012, at 16:31, Rob Cernich wrote:

> Hey Max,
> 
> Thanks for the reply.  My immediate need was to allow the inclusion of component specific dependencies and configuration within a SwitchYard project.  For example, when using BPM within a SwitchYard project, the SwitchYard BPM dependencies must be added to the POM and the SwitchYard configuration builder (mojo) must be configured to scan BPM files when generating the SwitchYard configuration.

Yes, but how ? are you using jboss tools maven integration for this which enables maven for WTP projects in general or how ?

> Given the above concrete example, I can either create a separate component facet that can be added to the project

Since it is "simply" manipulating pom.xml based on switchyard being in there or not I would say this does not require a sub-facet ?

> or I can have a SwitchYard property page on the project that can be used for configuring SwitchYard capabilities on the project.  In the latter case, that could even mean applying component facets when the user modifies the configuration.

That is what the Facet configuration UI or the Configure Project submenu is for….wether there is a property page or not I'm not sure. Doesn't hurt I guess.

What need to be considered too is what happens when you import the a switchyard maven pom project - then I assume you have a m2e configurator that enables this switchyard facet based on the presence of the dependencies, switchyard config file or the switchyard mojo ?

> The main reason I was considering facets for components was the ability to specify requirements on other facets (e.g. SwitchYard Bean component requires CDI), which (I'm assuming here) would enable existing tooling functionality for those required facets on the project (CDI, BPEL, etc.).  (It's also a convenient way for adding/removing component functionality, through the Project Facets property page.)  However, if this is not the case, then I probably don't need to worry about facets for component specific functionality.

That is what facets are for but SwitchYard is not the place to specify BPEL and BPMN facets is it ? That should be in those respective plugins and then you configure your facet based on this?

> Some more background on SwitchYard in general.  SwitchYard functionality can be included in any JEE archive.  The simplest case is a stand-alone SwitchYard application, which is packaged and deployed as a utility JAR.  However, the SwitchYard facet may be added to an existing WEB project (so long as it's a Maven based project), which configures the project appropriately for SwitchYard.

Is that Maven stuff a hard requirement for this to work ?  Sounds weird to me ?

> 
> Thanks again for the info.
> 
> Best,
> Rob
> 
> ----- Original Message -----
>> 
>>> Does anybody have experience adding facets for technologies that
>>> use configurable components?
>> 
>> Yes.
>> 
>>> I'm in the process of integrating the SwitchYard tooling with WTP.
>>> SwitchYard contains multiple components which allow the developer
>>> to integrated with various technologies (e.g. BPM, CDI, Camel,
>>> etc.).  From the following, wich is best?
>> 
>> The answer depends a lot on what these things are supposed to do ?
>> 
>> Are they generating new artifacts that are "just" basic "markers"
>> (manifest.mf, beans.xml, persistence.xml) or more complex ones (jpa
>> mapping files, descriptors with actual content etc.) ? Can they be
>> done "standalone" or is it all part of one big "enablement" which
>> just *has* to happen in a specific sequence?
>> 
>> If the latter, then a Wizard is probably best - if all small
>> individual steps that can be captured in Facet's dependency model
>> and installation hooks mechanism then it *could* be a facet - but
>> you see even with something as simple as "creating a manifest.mf" it
>> might be a bad thing for some, bad for others ;)
>> 
>>> 1. Use a single SwitchYard facet, along with a property page that
>>> allows the user to select various component support.
>> 
>> Depends what they do…i.e. a SwitchYard Facet should not enable CDI
>> explicitly, it should support (or even require?) the CDI facet.
>> 
>> If its a "generate a camel" descriptor file and there are no real
>> Camel facet or tooling already then having that as part of the facet
>> could be
>> ok.
>> 
>> The main thing is that facets should be installable with minimal fuzz
>> - i.e. not a lot of complexity.
>> 
>> If it requires more then a Wizard to setup the right things might be
>> a better way and just let the Facet concentrate about the basics
>> (i.e. add the marker files, enable the natures etc.)
>> 
>>> 2. Create a facet for each component type.  (I'd probably group
>>> these under a "SwitchYard Components" category.)
>> 
>> depends what they do…Facets should not be too fine-grained IMO.
>> 
>>> 3. Other???
>>> 
>>> I'm leaning toward option 2, since those facets could be
>>> constrained to include other facets (e.g. BPEL), but it also seems
>>> a bit cumbersome.
>> 
>> Need more details to answer.
>> 
>> The worst thing that could happen is "spaghetti" facets where a set
>> of facets can't work without the other facets being *just* right ….
>> 
>> /max
>> http://about.me/maxandersen
>> 
>> 
>> 
>> 

/max
http://about.me/maxandersen