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