[Hawkular-dev] Hawkular integration

[John Mazzitelli]

At the F2F breakout session we had, we had talked about doing the following (though I've since heard that this might not be what we are going to do - instead, perhaps use something like war overlays - so take this with a grain of salt):

Each component should have two assemblies - one is a "core" assembly and the other is a "hawkular" assembly

The "core" assembly is the standalone product - for example, this would be H-Metrics that can be deployed on its own, standalone. This is to support our requirement that things like Hawkualr-Metrics must be able to run standalone outside of a full blown Hawkular environment.

The "hawkular" assembly is nothing more than the "core" assembly with an addition jar (or multiple jars, whatever they want to do) that contains the hawkular "glue" code. The "glue" code would be things like CDI listeners, bus listeners, bus producers.

We had come up with a design to allow the "core" assembly to run standalone but if in "hawkular" deployment, that glue code would be the way it hooks into the hawkular environment (e.g. a CDI listener would listen for the component to start up, and install a bus listener to listen for hawkular messages over the bus).

The assembly plugin would merely just add the glue code artifacts (the jar files) to the core build. 

So I envision something like this (as a maven layout) - this is a "psuedo" layout:

hawkular-metrics/parent
                   |
                   |----- core API (jar artifact)
                   |
                   |----- webapp (war artifact)
                   |
                   |----- glue code (jar artifact)
                   |
                   |----- dist

The "dist" maven module would build two assemblies - one that has the webapp+coreAPI ("core") and the other would be "core" + the glue code artifact jar shoved in, say, WEB-INF/lib (this jar is the thing that contains the CDI listeners, bus listeners, bus products, whatever).

Now, if you don't want to put the glue code in each component's repo, just put them wherever and just have a dependency on that glue code artifact in the "dist" maven module for the component that pulls it in.

This is similar to Heiko's idea of taking the Metrics WAR and in the kettle build just crack it open, put the glue code jar in the WEB-INF/lib, and re-archive the war. This design I mention above is just a formalization of that - its just how you would do it without messing with artifacts that come from the maven repo. I personally have a problem with us taking an artifact from the maven repo, cracking it open and modifying it, zipping it back up and THEN using that in the product. I much prefer that we put into the maven repository what we plan on actually deploying and running with. Just seems like there is a risk if our build processes modify artifacts before using them.

There was a concern about classloading issues and that perhaps we need an "uber" ear that wraps all the components. We need someone to experiment with that idea. That is a question we need to answer ("do we need a uber ear in kettle?").

Anyway, that's what we talked about (among other things) in that F2F break out session (which I thought was one of the most productive sessions we had :)


----- Original Message -----
> I don't think this answers the question.
> 
> Or at least it's not clear what you suggest in terms of where the
> integration code with the bus should happen.
> 
> It's not clear to me what you mean by "standalone deployments".
> 
> Thomas
> 
> 
> 
> On 05/20/2015 02:38 PM, John Mazzitelli wrote:
> > Which is why we agreed at the F2F to have REST endpoints as the component
> > interface that clients would use, but have a "hawkular" assembly that
> > would include extra bus listeners/producers that would talk to other
> > hawkular components when deployed in a Hawkular environment.  This was the
> > dual assembly idea (one with just core pieces, for standalone deployments,
> > and another one that included hawkular glue code that allowed it to run in
> > a hawkular environment).
> >
> > ----- Original Message -----
> >> On 20 May 2015, at 11:19, Thomas Heute wrote:
> >>> I think a library can be reused, or Hawkular metrics can be reused as
> >>> standalone project. I hardly think that a component depending on the bus
> >>> would be reused by anyone.
> >>
> >> +1
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
>