Hi,
I disagree with the fact where the actual bus-integration component should reside. The
components themselves should have the capabilities of allowing another component to
connect to their internal "feeds" but the actual component -> bus connector
should be in the Kettle-repository. Why? The bus-connector is highly dependent on the
actual bus implementation. If we would change the bus in any way in terms of
implementation or API, it would require changes to every Hawkular component (thus, they
wouldn't be decoupled by design) instead of only changing the implementation at the
bus-component.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, May 13, 2015 11:02:31 AM
Subject: [Hawkular-dev] The components, glue and kettle
Hi
On yesterday's watercooler discussion the main topic was about how to package the
individual components, with the "glue" code, within kettle.
There seems to be a general idea to move all bus integration code into Hawkular/Kettle
repo. Although I agree that the kettle is the right place to bring together the components
and glue, not sure whether the actual code for the glue should reside in that single
repo.
My preference would be for all component related code, including that component's
integration with the bus, to be located in that component repo - that way there is a clear
owner of the code, and any changes to the core APIs are locally dealt across all
integration points that may be supported.
Then the kettle repo can be responsible for selecting the relevant artifacts to build what
it requires.
In terms of how the 'core' artifacts from each component should be enhanced with
the glue - may be the simplest way would be as one person suggested - use an overlay to
build upon the 'core' war artifact to add the glue artifacts (which in general
will probably just be bus integration). So each component only needs to produce a single
'core' war, but also manages the integration artifacts locally.
I think I would prefer this approach over a single ear, as it still retains the individual
component boundaries but enhances them with whatever they need to communicate in the
kettle.
It would be even more ideal if jboss modules allowed exploded wars, so that we didn't
need to use overlays, but I don't believe this is the case.
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev