On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp@redhat.com> wrote:

Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga@redhat.com>:
Second, the possibility to run in a non-WF-like container is still
somewhere in my consciousness. Importing wf BoM does not seem to be a
step in that direction.

Yes. We need to restrict ourselves to Java EE 6 and EJB 3.1, JMS 1.1 apis.
We can use what EAP 6.4 offers - including JAX-RS 2 (this is not in there by default, but
can be supplied by the application).
This does not imply that we have to develop on EAP 6.4 though.

These two statements are contradicting each other: running in a “non WF-like” container and assuming EE6 API’s on the target platform are two worlds apart.

First of all, if you build on EE6, you don’t “restrict” yourself. At least not in the way of “limiting” the API dependencies. But limiting the API dependencies is a prerequisite to successfully integrate with other platforms (or containers), which is what Peter has in mind, if I am correct.

Hawkular want’s to provide a set of re-usable components. Re-usable in a sense, that other software project can integrate them easily. On the other hand there is the goal to build a Hawkular application, which itself is a consumer of the before mentioned components.

I think the continuous mistake among the Hawkular contributors is that you don’t prioritise these two approaches. To do that, we need to acknowledge an intrinsic dependency of the Hawkular application onto the components. Furthermore, any decision of API and service dependencies of those components impacts the way in which they can be re-used. Dependencies would need to be carried over to any platform that want’s to leverage Hawkular components. Which, in a way, limits it’s reusability.

My suggestion would be to prioritise on the component re-use. Even if that results in inconveniences when building the Hawkular application: