Does anybody have experience adding facets for technologies that use configurable components?

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?

1. Use a single SwitchYard facet, along with a property page that allows the user to select various component support.

2. Create a facet for each component type. (I'd probably group these under a "SwitchYard Components" category.)

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.

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.

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

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.

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.

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.

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

> Yes, but how ? are you using jboss tools maven integration for this > which enables maven for WTP projects in general or how ? I use m2e, with a soft dependency on JBT Maven integration. (I use a dynamic preset for the "core" SwitchYard settings, which includes jboss.m2 if it is available.) m2e-wtp provides configurators for setting up the deployables correctly. As for adding the dependencies, that's just straight m2e. And facet configuration is done by a m2e project configurator which detects the presence of the SwitchYard mojo. If you'd like to see the current implementation, it resides here: https://github.com/jboss-switchyard/tools/tree/master/eclipse/plugins/org...

>> 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 ? Yes, but it would also enable complementary facets (e.g. BPEL), which I assume would enable other tools on the project (e.g. validators).

>> 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. That allows the facet set to be configured, but doesn't directly support configuration of the individual facets once they've been installed.

>> 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? I think it really depends on what the user does. If they create a SwitchYard project, then decide they want to add a BPEL service, the project settings will be updated appropriately (by SwitchYard).

>> 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 ? I suppose it may be, but the SwitchYard configuration generator only exists in a Maven mojo. A user could always hand-code everything and JAR it up themselves.