2:09 p.m.
Currently integration components, particularly those that interact with the bus, live in
the respective component repos. I have been working with Peter on HAWKULAR-844 to migrate
the bus from ActiveMQ to the default messaging subsystem in WildFly 10, which is based on
ActiveMQ Artemis. While working on this, I started to wonder if all of the integration
components should live in the same repo. Let’s say I make a breaking change in the bus,
then we have to update and cut releases for each of the component repos, which is
currently five or six. If the integration components live in the same repo as the bus, it
is much easier to make the changes and we only have one new release to worry about.
Keeping the integration components in the same repo should also help reduce the number of
dependencies in each of the component repos which makes development on any one of them
easier. I want to know what people think because once HAWKULAR-844 is done, I would like
to consider some refactoring in the bus code to utilize JMS 2.0 APIs including support for
async sending/receiving messages. This would likely entail breaking changes.
- John
2:34 p.m.
Hi John, I was about to write a message on this topic now after I spoke
with mazz :)
integration components, particularly those that interact
with the bus, live in the respective component repos.
I am not 100% sure which are "integration components" for you.
Nevertheless, mazz and me agree to move the "new Bus" (after
HAWKULAR-844) and "new Nest"
(https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons
git repository. I'll write more about the proposal in the next message.
-- P
On 2015-12-01 21:09, John Sanda wrote:
Currently integration components, particularly those that interact
with the bus, live in the respective component repos. I have been
working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ
to the default messaging subsystem in WildFly 10, which is based on
ActiveMQ Artemis. While working on this, I started to wonder if all
of the integration components should live in the same repo. Let’s say
I make a breaking change in the bus, then we have to update and cut
releases for each of the component repos, which is currently five or
six. If the integration components live in the same repo as the bus,
it is much easier to make the changes and we only have one new
release to worry about. Keeping the integration components in the
same repo should also help reduce the number of dependencies in each
of the component repos which makes development on any one of them
easier. I want to know what people think because once HAWKULAR-844 is
done, I would like to consider some refactoring in the bus code to
utilize JMS 2.0 APIs including support for async sending/receiving
messages. This would likely entail breaking changes.
- John _______________________________________________ hawkular-dev
mailing list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:50 p.m.
I am primarily talking about bus integration which would include things like,
* hawkular-metrics-component
* hawkular-alerts-bus
* hawkular-alerts-bus
* hawkular-alerts-actions-bus
* hawkular-inventory-bus-api
* hawkular-inventory-bus
Once we move to WF 10, we will drop the bus subsystem in favor of the default messaging
subsystem. All that remains of the bus is a shared, common library. It will no longer have
(or need to have) any relationship/dependency with the nest. I wonder if the bus
integration components should live in the main hawkular repo. If we have integration tests
involving these components that run in a hawkular server, then I think from a development
stand point, it makes things easier if they live in the main hawkular repo.
On Dec 1, 2015, at 3:34 PM, Peter Palaga <ppalaga(a)redhat.com>
wrote:
Hi John, I was about to write a message on this topic now after I spoke
with mazz :)
> integration components, particularly those that interact
> with the bus, live in the respective component repos.
I am not 100% sure which are "integration components" for you.
Nevertheless, mazz and me agree to move the "new Bus" (after
HAWKULAR-844) and "new Nest"
(https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons
git repository. I'll write more about the proposal in the next message.
-- P
On 2015-12-01 21:09, John Sanda wrote:
> Currently integration components, particularly those that interact
> with the bus, live in the respective component repos. I have been
> working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ
> to the default messaging subsystem in WildFly 10, which is based on
> ActiveMQ Artemis. While working on this, I started to wonder if all
> of the integration components should live in the same repo. Let’s say
> I make a breaking change in the bus, then we have to update and cut
> releases for each of the component repos, which is currently five or
> six. If the integration components live in the same repo as the bus,
> it is much easier to make the changes and we only have one new
> release to worry about. Keeping the integration components in the
> same repo should also help reduce the number of dependencies in each
> of the component repos which makes development on any one of them
> easier. I want to know what people think because once HAWKULAR-844 is
> done, I would like to consider some refactoring in the bus code to
> utilize JMS 2.0 APIs including support for async sending/receiving
> messages. This would likely entail breaking changes.
>
> - John _______________________________________________ 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
3:49 p.m.
On 2015-12-01 21:50, John Sanda wrote:
I am primarily talking about bus integration which would include
things like,
* hawkular-metrics-component
* hawkular-alerts-bus
* hawkular-alerts-bus
* hawkular-alerts-actions-bus
* hawkular-inventory-bus-api
* hawkular-inventory-bus
Ah OK, this is a little bit different area than I wanted to speak about.
Once we move to WF 10, we will drop the bus subsystem in favor of
the
default messaging subsystem. All that remains of the bus is a shared,
common library. It will no longer have (or need to have) any
relationship/dependency with the nest. I wonder if the bus integration
components should live in the main hawkular repo. If we have
integrationtests involving these components that run in a hawkular
server, then I think from a development stand point, it makes things
easier if they live in the main hawkular repo.
I agree that integration tests should be located as close as possible to
the components they are testing, ideally the tests should be located in
the same git repository as the components tested.
However, we cannot move bus-common to HK main, at least because that
would introduce circular dependencies between HK main on one side and
Agent and Command Gateway on the other side.
-- P
> On Dec 1, 2015, at 3:34 PM, Peter Palaga <ppalaga(a)redhat.com> wrote:
>
> Hi John, I was about to write a message on this topic now after I spoke
> with mazz :)
>
>> integration components, particularly those that interact
>> with the bus, live in the respective component repos.
>
> I am not 100% sure which are "integration components" for you.
>
> Nevertheless, mazz and me agree to move the "new Bus" (after
> HAWKULAR-844) and "new Nest"
> (https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons
> git repository. I'll write more about the proposal in the next message.
>
> -- P
>
> On 2015-12-01 21:09, John Sanda wrote:
>> Currently integration components, particularly those that interact
>> with the bus, live in the respective component repos. I have been
>> working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ
>> to the default messaging subsystem in WildFly 10, which is based on
>> ActiveMQ Artemis. While working on this, I started to wonder if all
>> of the integration components should live in the same repo. Let’s say
>> I make a breaking change in the bus, then we have to update and cut
>> releases for each of the component repos, which is currently five or
>> six. If the integration components live in the same repo as the bus,
>> it is much easier to make the changes and we only have one new
>> release to worry about. Keeping the integration components in the
>> same repo should also help reduce the number of dependencies in each
>> of the component repos which makes development on any one of them
>> easier. I want to know what people think because once HAWKULAR-844 is
>> done, I would like to consider some refactoring in the bus code to
>> utilize JMS 2.0 APIs including support for async sending/receiving
>> messages. This would likely entail breaking changes.
>>
>> - John _______________________________________________ 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
2:04 a.m.
I think if all that will remain is a common library, which I guess will be located in
hawkular-commons, then it would be better for the integration code to remain with their
components.
Although this work may be disruptive and result in changes in multiple repos, I still see
the bus as plumbing and it should result in a stable API. Whereas the component code that
uses the bus is more likely to change, and therefore it would be easier for the component
developers to have their code in one place.
Regards
Gary
----- Original Message -----
I am primarily talking about bus integration which would include
things like,
* hawkular-metrics-component
* hawkular-alerts-bus
* hawkular-alerts-bus
* hawkular-alerts-actions-bus
* hawkular-inventory-bus-api
* hawkular-inventory-bus
Once we move to WF 10, we will drop the bus subsystem in favor of the default
messaging subsystem. All that remains of the bus is a shared, common
library. It will no longer have (or need to have) any
relationship/dependency with the nest. I wonder if the bus integration
components should live in the main hawkular repo. If we have integration
tests involving these components that run in a hawkular server, then I think
from a development stand point, it makes things easier if they live in the
main hawkular repo.
> On Dec 1, 2015, at 3:34 PM, Peter Palaga <ppalaga(a)redhat.com> wrote:
>
> Hi John, I was about to write a message on this topic now after I spoke
> with mazz :)
>
>> integration components, particularly those that interact
>> with the bus, live in the respective component repos.
>
> I am not 100% sure which are "integration components" for you.
>
> Nevertheless, mazz and me agree to move the "new Bus" (after
> HAWKULAR-844) and "new Nest"
> (https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons
> git repository. I'll write more about the proposal in the next message.
>
> -- P
>
> On 2015-12-01 21:09, John Sanda wrote:
>> Currently integration components, particularly those that interact
>> with the bus, live in the respective component repos. I have been
>> working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ
>> to the default messaging subsystem in WildFly 10, which is based on
>> ActiveMQ Artemis. While working on this, I started to wonder if all
>> of the integration components should live in the same repo. Let’s say
>> I make a breaking change in the bus, then we have to update and cut
>> releases for each of the component repos, which is currently five or
>> six. If the integration components live in the same repo as the bus,
>> it is much easier to make the changes and we only have one new
>> release to worry about. Keeping the integration components in the
>> same repo should also help reduce the number of dependencies in each
>> of the component repos which makes development on any one of them
>> easier. I want to know what people think because once HAWKULAR-844 is
>> done, I would like to consider some refactoring in the bus code to
>> utilize JMS 2.0 APIs including support for async sending/receiving
>> messages. This would likely entail breaking changes.
>>
>> - John _______________________________________________ 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
3:12 a.m.
Everything has pros and cons.
If we move the glue projects into hawkular repo, yes a change in the bus will be easier to
manager.
On the contrary, a change on the component will need an additional update into the
hawkular repo.
So, synchronization is needed in one side of another.
For alerts, that we relied on the bus for the integration metrics and also internally for
plugins integration we worked fine with the components in alerts repo.
As a change in the bus is rare (like this, once WF10 is out, I don't think a change
here is going to be frequent), but on the contrary a change on these projects are pretty
normal.
So based on how we worked, for us, it would be better to maintain them on the component,
to have all component-related-logic together.
I agree that perhaps it might be parts shared that can be extracted and placed in a
commons location, but most of the logic should remamin in the component IMO.
Lucas
----- Original Message -----
From: "John Sanda" <jsanda(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Tuesday, December 1, 2015 9:50:12 PM
Subject: Re: [Hawkular-dev] Where should integration components live?
I am primarily talking about bus integration which would include things like,
* hawkular-metrics-component
* hawkular-alerts-bus
* hawkular-alerts-bus
* hawkular-alerts-actions-bus
* hawkular-inventory-bus-api
* hawkular-inventory-bus
Once we move to WF 10, we will drop the bus subsystem in favor of the default
messaging subsystem. All that remains of the bus is a shared, common
library. It will no longer have (or need to have) any
relationship/dependency with the nest. I wonder if the bus integration
components should live in the main hawkular repo. If we have integration
tests involving these components that run in a hawkular server, then I think
from a development stand point, it makes things easier if they live in the
main hawkular repo.
> On Dec 1, 2015, at 3:34 PM, Peter Palaga <ppalaga(a)redhat.com> wrote:
>
> Hi John, I was about to write a message on this topic now after I spoke
> with mazz :)
>
>> integration components, particularly those that interact
>> with the bus, live in the respective component repos.
>
> I am not 100% sure which are "integration components" for you.
>
> Nevertheless, mazz and me agree to move the "new Bus" (after
> HAWKULAR-844) and "new Nest"
> (https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons
> git repository. I'll write more about the proposal in the next message.
>
> -- P
>
> On 2015-12-01 21:09, John Sanda wrote:
>> Currently integration components, particularly those that interact
>> with the bus, live in the respective component repos. I have been
>> working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ
>> to the default messaging subsystem in WildFly 10, which is based on
>> ActiveMQ Artemis. While working on this, I started to wonder if all
>> of the integration components should live in the same repo. Let’s say
>> I make a breaking change in the bus, then we have to update and cut
>> releases for each of the component repos, which is currently five or
>> six. If the integration components live in the same repo as the bus,
>> it is much easier to make the changes and we only have one new
>> release to worry about. Keeping the integration components in the
>> same repo should also help reduce the number of dependencies in each
>> of the component repos which makes development on any one of them
>> easier. I want to know what people think because once HAWKULAR-844 is
>> done, I would like to consider some refactoring in the bus code to
>> utilize JMS 2.0 APIs including support for async sending/receiving
>> messages. This would likely entail breaking changes.
>>
>> - John _______________________________________________ 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
2:36 p.m.
Similarly, what about the things in hawkular repo's "modules" directory?
Shouldn't those also be moved to the same common repo? Maybe they can't for
technical reasons, but it think we should at least look into it, especially if we are
considering moving components to a common repo.
----- Original Message -----
Currently integration components, particularly those that interact
with the
bus, live in the respective component repos. I have been working with Peter
on HAWKULAR-844 to migrate the bus from ActiveMQ to the default messaging
subsystem in WildFly 10, which is based on ActiveMQ Artemis. While working
on this, I started to wonder if all of the integration components should
live in the same repo. Let’s say I make a breaking change in the bus, then
we have to update and cut releases for each of the component repos, which is
currently five or six. If the integration components live in the same repo
as the bus, it is much easier to make the changes and we only have one new
release to worry about. Keeping the integration components in the same repo
should also help reduce the number of dependencies in each of the component
repos which makes development on any one of them easier. I want to know what
people think because once HAWKULAR-844 is done, I would like to consider
some refactoring in the bus code to utilize JMS 2.0 APIs including support
for async sending/receiving messages. This would likely entail breaking
changes.
- John
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3365
days inactive
3366
days old
6 comments
5 participants
participants (5)
-
Gary Brown -
John Mazzitelli -
John Sanda -
Lucas Ponce -
Peter Palaga