On 02/16/2015 02:37 PM, Peter Palaga wrote: > Hi John, > > was there any discussion (that I may have missed during my PTO) around > importing the jboss-javaee-7.0-with-all to parent? Could you please > justify the idea once again for me? > > I must say I'd veto the change if I was at work. Here is why: > > (1) Tying to WildFly only. The change might be understood like this. I > am not sure this was your intention, but please consider that importing > another similar BoM (say EAP BoM) in paralel would in fact be extremely > impractical, because of version conflicts. > > (2) Pulling in many artifacts we do not use, do not need, some of them > maybe being implicitly unwanted ones. But having them in parent is > actually legalizing them without any discussion. That is especially > dangerous. > > (3) "Political" dependence on WildFly. WildFly may do changes at any > time in their BoMs that may have bad consequences in Hawkular. > > The bottom line is that it would be much better to avoid situations this > through discussing proposals prior to merging them in master. I have > proposed explicit parent contribution rules in > https://github.com/hawkular/hawkular-parent-pom/pull/13 Feel free to > comment on them. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev >

My bad - it has been my intention to never touch the parent pom (or global maven stuff in general) anymore. I slipped up here. I was only trying to keep everyone on the same version as the Wildfly container we are embedding in (so, for example, the integration assembly will work). Didn't think it would be a problem since we are all running in Wildfly (at least, that is how the integration assembly that heiko had me create is working). Not sure how we can ensure we all use all the same versions as provided by the container we are in unless we pull in the BOM, but perhaps there is another way. (BTW: this doesn't pull in all those dependencies, it is just pulling in the dependency definitions and individual projects pull in whatever deps they want with the provided scope.

But if there is a better way to ensure we keep on the same versions that the container provides, we can do that. > On 02/16/2015 02:37 PM, Peter Palaga wrote: >> Hi John, >> >> was there any discussion (that I may have missed during my PTO) >> around importing the jboss-javaee-7.0-with-all to parent? Could >> you please justify the idea once again for me? >> >> I must say I'd veto the change if I was at work. Here is why: >> >> (1) Tying to WildFly only. The change might be understood like >> this. I am not sure this was your intention, but please consider >> that importing another similar BoM (say EAP BoM) in paralel would >> in fact be extremely impractical, because of version conflicts. >> >> (2) Pulling in many artifacts we do not use, do not need, some of >> them maybe being implicitly unwanted ones. But having them in >> parent is actually legalizing them without any discussion. That >> is especially dangerous. >> >> (3) "Political" dependence on WildFly. WildFly may do changes at >> any time in their BoMs that may have bad consequences in >> Hawkular. >> >> The bottom line is that it would be much better to avoid >> situations this through discussing proposals prior to merging >> them in master. I have proposed explicit parent contribution >> rules in https://github.com/hawkular/hawkular-parent-pom/pull/13 >> Feel free to comment on them. >> _______________________________________________ hawkular-dev >> mailing list hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

From: "John Mazzitelli" <mazz(a)redhat.com&gt; To: hawkular-dev(a)lists.jboss.org Sent: Monday, February 16, 2015 9:17:35 AM Subject: Re: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent > First, I am not against including WildFly in some form. But I vote for > the least possible set. jboss-javaee-7.0-with-all [1] is unnecessarily > broad. Hibernate anyone? I didn't think it mattered because this doesn't import the dependencies anyway. It only imports the dependency definitions (so yeah if someone wants to use hibernate, they can pull it in if they want - but it is not like we now have a dependency on Hibernate just because the parent pom has the WF BOM in it. It is just letting us know what version of Hibernate we CAN pull in if we want to). But if we don't even want our sub-projects to even use EE/Wildfly dependencies, then I can see pulling it out (to avoid tempting them to use it?)

_______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: > > Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga(a)redhat.com <mailto: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.

On Friday, February 20, 2015 08:50:40 Heiko Braun wrote: > > On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: > >> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga(a)redhat.com > >> <mailto: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. > I guess the point the Heiko R. wanted to make is that by using jboss-javaee7 BoM or whatever BoM that defines versions of dependencies that are used in our *primary* target container, all we are doing is that we limit ourselves in a choice of versions of *potential* dependencies. By importing a BoM you don't actually depend on anything - you merely predefine the versions of artifacts you might want to depend on. All it does is it makes our lives easier when composing the integrated solution together. Otherwise everything you said resonates with me. The components themselves should be first of all embeddable as a library and therefore have only an absolutely necessary number of deps. REST API then becomes a facade on top of that. If we ever want to expose the components as EJBs, those EJBs would again be facades using the library. Etc. That's how I understood the outcome of our design discussions. While it may not look like it at the moment when we want to "rush" something (barely) consumable out to public, that outcome is definitely what we want to have in the "final" picture (or at least I sincerely hope so ;) ). Of course, embeddable libraries are only a small beginning. The picture gets more interesting when you start to think about integrations between the components (i.e actually fire an alert when some value flows into metrics). I actually am not sure we cracked that architectural nut such that we all are satisfied with it. A message bus of sorts lends itself as a solution to loosely coupled communication between the components but components themselves I think should not depend on the bus by default - if for nothing else than for the "baggage" of dependencies any of the message bus solutions carry with it. > My suggestion would be to prioritise on the component re-use. Even if that > results in inconveniences when building the Hawkular application: > > - Get rid of all EE6 dependencies. +1 > - Stop thinking in WAR and EAR deployments. +1 for components, -1 for their REST APIs and the integrated solution > - Support reusability by strictly limiting the API dependencies. +100 > - Come to an agreement about the priorities. I think the prios are clear - rush something "dirty" out now, clean up to our hearts' content right after the first version is out. > - Document and communicate the outcome of this discussion +1, we (and most of all I) need to get better at this > - Make sure all contributors understand and respect these constraints. > > Regards, Heiko B. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Alerting is frankly the most complex part of the big picture which Jay or LucasP are be much more qualified to comment on. But for example inventory is at its core just a simple CRUD interface. The only thing fancy about it is that it stores a graph with custom edges (and can do versioning, blah, blah). Inventory in and of itself doesn't interact with anything else. It could use JPA for example but that would unnecessarily tie it to RDBMs which it currently doesn't need (and uses a graph db instead). Of course, that changes when you want to integrate other stuff with inventory and create the "big picture". But only then one should think about using EE (or camel for that matter) stuff to help with that. Metrics is another example that could do without ee just fine imho. Again, only the integration layer really needs some of the EE features because of the bus and even then I think your bus works out of ee, too? I think the question coul also be what we DO absolutely necessary need that is best provided by EE. On Friday, February 20, 2015 09:26:12 John Mazzitelli wrote: > I don't understand the rush to get rid of EE6 and dependencies like that > (especially when we are rushing to get something done quickly). We have at > our disposal a nice EE API and deployment model that let's us "get work > done". If we don't, for example, use MDBs, we have to handle all of what > they do by ourselves. Same with the other types of constructs. > > I can see this restriction for things like wildfly-monitor where we embed a > collector of metrics that could go in Wildfly-Core. But for the integration > components (like alerts), to take away EE would be detrimental to the > development effort because think of all the infrastructure we'd have to > "re-invent" before we could do the actual work of alerting. > > What are the use-cases where we don't want EE? What components are we > talking about that shouldn't use EE? Maybe I'm missing the big picture?? > > ----- Original Message ----- > >> On Friday, February 20, 2015 08:50:40 Heiko Braun wrote: >>>> On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: >>>>> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga(a)redhat.com >>>>> <mailto: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. >> I guess the point the Heiko R. wanted to make is that by using >> jboss-javaee7 BoM or whatever BoM that defines versions of dependencies >> that are used in our >> *primary* target container, all we are doing is that we limit ourselves in >> a choice of versions of *potential* dependencies. By importing a BoM you >> don't actually depend on anything - you merely predefine the versions of >> artifacts you might want to depend on. All it does is it makes our lives >> easier when composing the integrated solution together. >> >> Otherwise everything you said resonates with me. The components themselves >> should be first of all embeddable as a library and therefore have only an >> absolutely necessary number of deps. >> >> REST API then becomes a facade on top of that. If we ever want to expose >> the components as EJBs, those EJBs would again be facades using the >> library. Etc. >> >> That's how I understood the outcome of our design discussions. While it >> may >> not look like it at the moment when we want to "rush" something (barely) >> consumable out to public, that outcome is definitely what we want to have >> in the "final" picture (or at least I sincerely hope so ;) ). >> >> Of course, embeddable libraries are only a small beginning. The picture >> gets more interesting when you start to think about integrations between >> the components (i.e actually fire an alert when some value flows into >> metrics). I actually am not sure we cracked that architectural nut such >> that we all are satisfied with it. A message bus of sorts lends itself as >> a solution to loosely coupled communication between the components but >> components themselves >> I think should not depend on the bus by default - if for nothing else than >> for >> the "baggage" of dependencies any of the message bus solutions carry with >> it.> >>> My suggestion would be to prioritise on the component re-use. Even if >>> that >>> results in inconveniences when building the Hawkular application: >>> >>> - Get rid of all EE6 dependencies. >> +1 >> >>> - Stop thinking in WAR and EAR deployments. >> +1 for components, -1 for their REST APIs and the integrated solution >> >>> - Support reusability by strictly limiting the API dependencies. >> +100 >> >>> - Come to an agreement about the priorities. >> I think the prios are clear - rush something "dirty" out now, clean up to >> our hearts' content right after the first version is out. >> >>> - Document and communicate the outcome of this discussion >> +1, we (and most of all I) need to get better at this >> >>> - Make sure all contributors understand and respect these constraints. >>> >>> Regards, Heiko B. >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Hi John, was there any discussion (that I may have missed during my PTO) around importing the jboss-javaee-7.0-with-all to parent? Could you please justify the idea once again for me? I must say I'd veto the change if I was at work. Here is why: (1) Tying to WildFly only. The change might be understood like this. I am not sure this was your intention, but please consider that importing another similar BoM (say EAP BoM) in paralel would in fact be extremely impractical, because of version conflicts. (2) Pulling in many artifacts we do not use, do not need, some of them maybe being implicitly unwanted ones. But having them in parent is actually legalizing them without any discussion. That is especially dangerous. (3) "Political" dependence on WildFly. WildFly may do changes at any time in their BoMs that may have bad consequences in Hawkular. The bottom line is that it would be much better to avoid situations this through discussing proposals prior to merging them in master. I have proposed explicit parent contribution rules in https://github.com/hawkular/hawkular-parent-pom/pull/13 Feel free to comment on them. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev