9:18 a.m.
Hi everyone,
I've been working on the changes needed in Metrics for the parent POM
upgrade to version 16 (those introducing Wildfly 9).
There are three things I noticed which I believe are worth sharing.
Firstly beware that the Wildfly guys have changed their philosophy about
the BOM: now they force the "provided" scope in the BOM and exclude all
the dependencies they think you shouldn't care about as a EE7
application developer.
On one hand it frees you from adding the provided scope declaration in
your application POM. On the other hand, if you use one of the artifacts
in tests then dependency resolution could suddenly be broken.
Secondly our parent POM does not only declare the Wildfly POM in
dependency management section, in also imports it. Which means that all
our projects get forced versioning and scope, even if they are not
Wildfly based.
Thirdly, minor issue, the Wildfly Maven plugin does not configure a
default Wildfly version which means that we are all forced to declare in
components parent POMs. Like this in Metrics:
https://github.com/hawkular/hawkular-metrics/blob/master/pom.xml#L190-L196
Going forward, I propose that we no longer "import" the BOM in Hawkular
parent, and let components do it where needed. And that we declare the
Wildfly version to start with the Wildfly Maven plugin in the parent.
Regards,
Thomas
9:25 a.m.
Firstly beware that the Wildfly guys have changed their philosophy
about
the BOM: now they force the "provided" scope in the BOM and exclude all
the dependencies they think you shouldn't care about as a EE7
application developer.
FWIW, I believe that violates common Maven practice for them to explicitly declare
provided scope in the BOM. They should change that. Has anyone asked them about it? I
thought you should never declare scope in dependencyManagement?
9:27 a.m.
Le 22/06/2015 16:25, John Mazzitelli a écrit :
> Firstly beware that the Wildfly guys have changed their
philosophy about
> the BOM: now they force the "provided" scope in the BOM and exclude all
> the dependencies they think you shouldn't care about as a EE7
> application developer.
FWIW, I believe that violates common Maven practice for them to explicitly declare
provided scope in the BOM. They should change that. Has anyone asked them about it? I
thought you should never declare scope in dependencyManagement?
I haven't. I found the issue before lunch and first sent this email.
9:52 a.m.
I've just sent a PR "Upgrade to Wildfly 9.0.0.Final"
https://github.com/hawkular/hawkular-parent-pom/pull/33
Note that:
- the Wildfly BOM is no longer forced on every project
- the Wildfly Maven plugin is configured to use our Wildfly version by
default, instead of the default version specified in the Maven plugin
Le 22/06/2015 16:18, Thomas Segismont a écrit :
Hi everyone,
I've been working on the changes needed in Metrics for the parent POM
upgrade to version 16 (those introducing Wildfly 9).
There are three things I noticed which I believe are worth sharing.
Firstly beware that the Wildfly guys have changed their philosophy about
the BOM: now they force the "provided" scope in the BOM and exclude all
the dependencies they think you shouldn't care about as a EE7
application developer.
On one hand it frees you from adding the provided scope declaration in
your application POM. On the other hand, if you use one of the artifacts
in tests then dependency resolution could suddenly be broken.
Secondly our parent POM does not only declare the Wildfly POM in
dependency management section, in also imports it. Which means that all
our projects get forced versioning and scope, even if they are not
Wildfly based.
Thirdly, minor issue, the Wildfly Maven plugin does not configure a
default Wildfly version which means that we are all forced to declare in
components parent POMs. Like this in Metrics:
https://github.com/hawkular/hawkular-metrics/blob/master/pom.xml#L190-L196
Going forward, I propose that we no longer "import" the BOM in Hawkular
parent, and let components do it where needed. And that we declare the
Wildfly version to start with the Wildfly Maven plugin in the parent.
Regards,
Thomas
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:06 a.m.
Hi Thomas,
As I noted in your PR
https://github.com/hawkular/hawkular-parent-pom/pull/33 if we remove
<scope>import</scope> from the WF BoM dependency, all artifacts declared
in the WF BoM will effectivelly become invisible in Hawkular projects.
The WF BoM dependency here in parent would thus become completely
useless (and can thus be removed completely), would it not?
As far as I can see your main motivation for this change was to stop
forcing Wildfly BOM on projects that do not need it. The way how we
should depend on WildFly BoM is a complicated topic. To build my own
position, I tried to figure out,
(1) which projects depend on artifacts from WF BoM and
(2) and which artifacts from WF BoM are those that any of the HK
projects depends on.
I did it only manually, using my eyes and IDE search - hence my findings
are rather sketchy.
My findings are as follows:
(i) WF BoM manages JBoss Logging. We manage it too [1] in the parent,
but that comes from pre-WF-BoM times and I'd personally found it better
not to have the logging deps in our parent and rather to rely on
versions imported from WF BoM (note that our logging versions got out of
date compared to WF9 BoM). The number of HK projects using JBoss logging
is pretty high: HK main, Accounts, Agent, Alerts, BTM, Bus and Inventory
(ii) WF BoM manages RESTeasy The number of HK projects using JBoss
logging is pretty high too: HK main, Accounts, Alerts, BTM, Bus,
Inventory and Metrics.
(iii) Then there is a substantial group of EE7 dependencies, like ejb,
javax.annotation, servlet, transaction, xml.rpc, jms, ... that are used
by HK main, Accounts, Bus, Commons (Embedded C*), Metrics and Inventory
Union of HK projects named in (i), (ii) and (iii) answers the question
(1) - the set of projects that depend on something managed in WF BoM:
HK main, Accounts, Agent, Alerts, BTM, Bus, Commons (Embedded C*),
Metrics and Inventory
Note that this pretty much equal to the list of projects that have
hawkular-parent as their parent. hawkular-android-client is not there,
but that is a special case that does not need to be considered.
So what happens if we remove the WF BoM import from the HK Parent? - I
see two options:
(a) we'd have to add the very same WF BoM import in every child of HK
Parent
or
(b) we'd have to manage the artifacts we need from WF BoM ourselves
in HK parent
I see no advantage in going with (a).
I used to prefer (b) earlier when I thought that Hawkular should target
other containers than those from the WF/EAP family. Apparently, we do
not target anything outside WF/EAP and (b) makes no sense to me anymore.
Based on the above, I'd say that we should keep the WF BoM import as is
in HK Parent.
Best,
Peter
[1]
https://github.com/hawkular/hawkular-parent-pom/blob/68227696f6fc9e102c81...
On 03/07/15 16:52, Thomas Segismont wrote:
I've just sent a PR "Upgrade to Wildfly 9.0.0.Final"
https://github.com/hawkular/hawkular-parent-pom/pull/33
Note that:
- the Wildfly BOM is no longer forced on every project
- the Wildfly Maven plugin is configured to use our Wildfly version by
default, instead of the default version specified in the Maven plugin
Le 22/06/2015 16:18, Thomas Segismont a écrit :
> Hi everyone,
>
> I've been working on the changes needed in Metrics for the parent POM
> upgrade to version 16 (those introducing Wildfly 9).
>
> There are three things I noticed which I believe are worth sharing.
>
> Firstly beware that the Wildfly guys have changed their philosophy about
> the BOM: now they force the "provided" scope in the BOM and exclude all
> the dependencies they think you shouldn't care about as a EE7
> application developer.
> On one hand it frees you from adding the provided scope declaration in
> your application POM. On the other hand, if you use one of the artifacts
> in tests then dependency resolution could suddenly be broken.
>
> Secondly our parent POM does not only declare the Wildfly POM in
> dependency management section, in also imports it. Which means that all
> our projects get forced versioning and scope, even if they are not
> Wildfly based.
>
> Thirdly, minor issue, the Wildfly Maven plugin does not configure a
> default Wildfly version which means that we are all forced to declare in
> components parent POMs. Like this in Metrics:
> https://github.com/hawkular/hawkular-metrics/blob/master/pom.xml#L190-L196
>
> Going forward, I propose that we no longer "import" the BOM in Hawkular
> parent, and let components do it where needed. And that we declare the
> Wildfly version to start with the Wildfly Maven plugin in the parent.
>
>
> Regards,
> Thomas
> _______________________________________________
> 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 a.m.
Le 14/07/2015 13:06, Peter Palaga a écrit :
Hi Thomas,
As I noted in your PR
https://github.com/hawkular/hawkular-parent-pom/pull/33 if we remove
<scope>import</scope> from the WF BoM dependency, all artifacts declared
in the WF BoM will effectivelly become invisible in Hawkular projects.
Yes, that's intended.
The WF BoM dependency here in parent would thus become completely
useless (and can thus be removed completely), would it not?
No it wouldn't, as Wildfly-based projects should all be using the same
BOM version.
As far as I can see your main motivation for this change was to stop
forcing Wildfly BOM on projects that do not need it. The way how we
should depend on WildFly BoM is a complicated topic. To build my own
position, I tried to figure out,
It's not important to me if 80, 90 or 99% of our projects our Wildfly
based. Importing the BOM in the parent POM gives the 1% projects no way
to escape.
If Hawkular projects want the BOM imported for all their submodules then
it's a matter of adding this in the component parent POM:
----
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>jboss-javaee-7.0-wildfly</artifactId>
<scope>import</scope>
</dependency>
----
Not too much to add (and that could have been included in the various PR
sent to upgrade to parent POM 18).
When this thread was started a month ago, we've agreed not forcing
scopes in dependency management sections. Then we've started discussions
with the Wildfly team and, thanks them, we got a Wildfly BOM version 9
without the forced scopes. Now we're doing the opposite in our own parent...
5:40 a.m.
Hi Thomas, inline...
On 2015-07-20 10:49, Thomas Segismont wrote:
Le 14/07/2015 13:06, Peter Palaga a écrit :
> Hi Thomas,
>
> As I noted in your PR
> https://github.com/hawkular/hawkular-parent-pom/pull/33 if we remove
> <scope>import</scope> from the WF BoM dependency, all artifacts declared
> in the WF BoM will effectivelly become invisible in Hawkular projects.
Yes, that's intended.
> The WF BoM dependency here in parent would thus become completely
> useless (and can thus be removed completely), would it not?
No it wouldn't, as Wildfly-based projects should all be using the same
BOM version.
OK, I can see now how you meant it.
> As far as I can see your main motivation for this change was to
stop
> forcing Wildfly BOM on projects that do not need it. The way how we
> should depend on WildFly BoM is a complicated topic. To build my own
> position, I tried to figure out,
It's not important to me if 80, 90 or 99% of our projects our Wildfly
based. Importing the BOM in the parent POM gives the 1% projects no way
to escape.
In my last message I claim to have shown that it is effectivelly 100% of
components. Which specific project "needs to escape" from your point of
view?
If Hawkular projects want the BOM imported for all their submodules
then
it's a matter of adding this in the component parent POM:
----
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>jboss-javaee-7.0-wildfly</artifactId>
<scope>import</scope>
</dependency>
----
Not too much to add (and that could have been included in the various PR
sent to upgrade to parent POM 18).
When this thread was started a month ago, we've agreed not forcing
scopes in dependency management sections. Then we've started discussions
with the Wildfly team and, thanks them, we got a Wildfly BOM version 9
without the forced scopes.
Sorry, I must have overseen that you were asking WF team to remove the
scopes from their management. From your mails understood rather the
opposite, namely, that they added provided scope, that we need to adapt to.
Is this where they did what you asked for?
https://github.com/wildfly/boms/commit/9e568fe4eb41d978c3181a90b5bb4d389e...
- because that's where they removed provided from resteasy but all the
rest stood provided.
And sorry, that I started to think about the real consequences only when
I saw your PR.
Thanks,
Peter
Now we're doing the opposite in our own parent...
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:36 a.m.
Le 20/07/2015 12:40, Peter Palaga a écrit :
In my last message I claim to have shown that it is effectivelly 100%
of
components. Which specific project "needs to escape" from your point of
view?
100% of components have at least one module to be deployed in Hawkular.
But then there are modules meant to run out of Hawkular (ptrans in
Metrics) or relevant to development only (rest-tests, load-testing,
Openshift v3 tests).
Sorry, I must have overseen that you were asking WF team to remove
the
scopes from their management. From your mails understood rather the
opposite, namely, that they added provided scope, that we need to adapt to.
Not sure how that could have been made easier to read, my original email
ends with "Going forward, I propose that we no longer "import" the BOM
in Hawkular parent".
Is this where they did what you asked for?
https://github.com/wildfly/boms/commit/9e568fe4eb41d978c3181a90b5bb4d389e...
- because that's where they removed provided from resteasy but all the
rest stood provided.
Yes. There was an agreement that the changes made to the Resteasy
section were wrong. They didn't change the rest because (I'm
paraphrasing) the BOM is meant to be imported by WAR/JAR/EAR modules to
be deployed to Wildfly.
And sorry, that I started to think about the real consequences only
when
I saw your PR.
OK. What's next? Are you going to reopen a PR in parent POM to remove
the import scope?
9:15 a.m.
On 2015-07-20 14:36, Thomas Segismont wrote:
Le 20/07/2015 12:40, Peter Palaga a écrit :
> In my last message I claim to have shown that it is effectivelly 100% of
> components. Which specific project "needs to escape" from your point of
> view?
100% of components have at least one module to be deployed in Hawkular.
But then there are modules meant to run out of Hawkular (ptrans in
Metrics) or relevant to development only (rest-tests, load-testing,
Openshift v3 tests).
Yes, I agree there exist maven modules inside HK componets projects that
do not consume anything from WF BoM. ptrans is a good example of such
one. But I am still failing to see what your proposal is going to
improve in ptrans. WF BoM, regardless if it is imported in parent or
not, has no influence on ptrans as long as you do not add a dependency
on something from the WF BoM. ptrans does not depend on anything managed
in WF BoM, hence there is no impact. The compile class path of ptrans
and the resulting jar stay the same regardless if WF BoM is imported in
HK parent or not. I see no impact at all.
I think I understand now how your proposal is supposed to work, but I
fail to see why it is better than the present state.
Thanks,
-- P
> Sorry, I must have overseen that you were asking WF team to
remove the
> scopes from their management. From your mails understood rather the
> opposite, namely, that they added provided scope, that we need to adapt to.
Not sure how that could have been made easier to read, my original email
ends with "Going forward, I propose that we no longer "import" the BOM
in Hawkular parent".
> Is this where they did what you asked for?
> https://github.com/wildfly/boms/commit/9e568fe4eb41d978c3181a90b5bb4d389e...
> - because that's where they removed provided from resteasy but all the
> rest stood provided.
Yes. There was an agreement that the changes made to the Resteasy
section were wrong. They didn't change the rest because (I'm
paraphrasing) the BOM is meant to be imported by WAR/JAR/EAR modules to
be deployed to Wildfly.
> And sorry, that I started to think about the real consequences only when
> I saw your PR.
OK. What's next? Are you going to reopen a PR in parent POM to remove
the import scope?
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:06 a.m.
Le 20/07/2015 16:15, Peter Palaga a écrit :
Yes, I agree there exist maven modules inside HK componets projects
that
do not consume anything from WF BoM. ptrans is a good example of such
one. But I am still failing to see what your proposal is going to
improve in ptrans. WF BoM, regardless if it is imported in parent or
not, has no influence on ptrans as long as you do not add a dependency
on something from the WF BoM. ptrans does not depend on anything managed
"as long as" is the key. When we upgraded from Wildfly BOM version 8 to
9.CR1, I spent half a day getting down to a build issue in Metrics,
where the rest-tests module suddenly stopped working, just because the
new BOM broke dependency resolution.
in WF BoM, hence there is no impact. The compile class path of
ptrans
and the resulting jar stay the same regardless if WF BoM is imported in
HK parent or not. I see no impact at all.
I think I understand now how your proposal is supposed to work, but I
fail to see why it is better than the present state.
It boils down to control of dependency management. With the BOM auto
imported by the parent, we have to adapt to the Wildfly BOM choices. It
should not be like this.
10:24 a.m.
Hello,
I agree and support ThomasS proposal primarily because of Hawkular Metrics integration
requirements. He has very valid points that fit perfectly in the requirements for the
project. I would like to see the proposal implemented as soon as possible.
Thank you,
Stefan
----- Original Message -----
From: "Thomas Segismont" <tsegismo(a)redhat.com>
To: hawkular-dev(a)lists.jboss.org
Sent: Monday, July 20, 2015 10:06:28 AM
Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
Le 20/07/2015 16:15, Peter Palaga a écrit :
> Yes, I agree there exist maven modules inside HK componets projects that
> do not consume anything from WF BoM. ptrans is a good example of such
> one. But I am still failing to see what your proposal is going to
> improve in ptrans. WF BoM, regardless if it is imported in parent or
> not, has no influence on ptrans as long as you do not add a dependency
> on something from the WF BoM. ptrans does not depend on anything managed
"as long as" is the key. When we upgraded from Wildfly BOM version 8 to
9.CR1, I spent half a day getting down to a build issue in Metrics,
where the rest-tests module suddenly stopped working, just because the
new BOM broke dependency resolution.
> in WF BoM, hence there is no impact. The compile class path of ptrans
> and the resulting jar stay the same regardless if WF BoM is imported in
> HK parent or not. I see no impact at all.
>
> I think I understand now how your proposal is supposed to work, but I
> fail to see why it is better than the present state.
It boils down to control of dependency management. With the BOM auto
imported by the parent, we have to adapt to the Wildfly BOM choices. It
should not be like this.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:50 a.m.
On 2015-07-20 17:06, Thomas Segismont wrote:
Le 20/07/2015 16:15, Peter Palaga a écrit :
> Yes, I agree there exist maven modules inside HK componets projects that
> do not consume anything from WF BoM. ptrans is a good example of such
> one. But I am still failing to see what your proposal is going to
> improve in ptrans. WF BoM, regardless if it is imported in parent or
> not, has no influence on ptrans as long as you do not add a dependency
> on something from the WF BoM. ptrans does not depend on anything managed
"as long as" is the key. When we upgraded from Wildfly BOM version 8 to
9.CR1, I spent half a day getting down to a build issue in Metrics,
where the rest-tests module suddenly stopped working, just because the
new BOM broke dependency resolution.
I can follow how hard it was to resolve the issue caused by WF BoM. But
anyway, even if WF BoM was not imported in HK parent, are you not going
to keep using the resteasy managed by WF BoM in rest-tests through
keeping it imported somewhere in the rest-tests pom hierarchy?
You maybe prefer to manage the resteasy client version yourself? -
because otherwise, I do not see how not having WF BoM imported in HK
parent would improve something important for you.
> in WF BoM, hence there is no impact. The compile class path of
ptrans
> and the resulting jar stay the same regardless if WF BoM is imported in
> HK parent or not. I see no impact at all.
>
> I think I understand now how your proposal is supposed to work, but I
> fail to see why it is better than the present state.
It boils down to control of dependency management. With the BOM auto
imported by the parent, we have to adapt to the Wildfly BOM choices.
Yes, that's true that we loose some control but the gain is that we do
not need to manage the versions of artifacts they manage.
You claim that there are modules where it is harmful. But which ones? In
ptrans, it is harmless, IMO (no dependency -> no problem). In
rest-tests, you probably keep WF BoM included anyway, so removing the WF
BoM include from HK Parent does not change anything. Is there any other
module where the WF BoM include in Parent causes a problem?
Thanks,
-- P
It
should not be like this.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
12:48 a.m.
Peter,
What would be a good argument to implement the removal of
<scope>import</scope> as proposed by Thomas?
Thank you,
Stefan
----- Original Message -----
From: "Peter Palaga" <ppalaga(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Monday, July 20, 2015 11:50:31 AM
Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
On 2015-07-20 17:06, Thomas Segismont wrote:
> Le 20/07/2015 16:15, Peter Palaga a écrit :
>> Yes, I agree there exist maven modules inside HK componets projects that
>> do not consume anything from WF BoM. ptrans is a good example of such
>> one. But I am still failing to see what your proposal is going to
>> improve in ptrans. WF BoM, regardless if it is imported in parent or
>> not, has no influence on ptrans as long as you do not add a dependency
>> on something from the WF BoM. ptrans does not depend on anything managed
>
> "as long as" is the key. When we upgraded from Wildfly BOM version 8 to
> 9.CR1, I spent half a day getting down to a build issue in Metrics,
> where the rest-tests module suddenly stopped working, just because the
> new BOM broke dependency resolution.
I can follow how hard it was to resolve the issue caused by WF BoM. But
anyway, even if WF BoM was not imported in HK parent, are you not going
to keep using the resteasy managed by WF BoM in rest-tests through
keeping it imported somewhere in the rest-tests pom hierarchy?
You maybe prefer to manage the resteasy client version yourself? -
because otherwise, I do not see how not having WF BoM imported in HK
parent would improve something important for you.
>> in WF BoM, hence there is no impact. The compile class path of ptrans
>> and the resulting jar stay the same regardless if WF BoM is imported in
>> HK parent or not. I see no impact at all.
>>
>> I think I understand now how your proposal is supposed to work, but I
>> fail to see why it is better than the present state.
>
> It boils down to control of dependency management. With the BOM auto
> imported by the parent, we have to adapt to the Wildfly BOM choices.
Yes, that's true that we loose some control but the gain is that we do
not need to manage the versions of artifacts they manage.
You claim that there are modules where it is harmful. But which ones? In
ptrans, it is harmless, IMO (no dependency -> no problem). In
rest-tests, you probably keep WF BoM included anyway, so removing the WF
BoM include from HK Parent does not change anything. Is there any other
module where the WF BoM include in Parent causes a problem?
Thanks,
-- P
> It
> should not be like this.
> _______________________________________________
> 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
1:35 a.m.
Le 20/07/2015 18:50, Peter Palaga a écrit :
On 2015-07-20 17:06, Thomas Segismont wrote:
I can follow how hard it was to resolve the issue caused by WF BoM. But
anyway, even if WF BoM was not imported in HK parent, are you not going
to keep using the resteasy managed by WF BoM in rest-tests through
keeping it imported somewhere in the rest-tests pom hierarchy?
You maybe prefer to manage the resteasy client version yourself? -
because otherwise, I do not see how not having WF BoM imported in HK
parent would improve something important for you.
Exactly, managing it manually, because we just want to consume RESTEasy
client in a pure itest module.
Yes, that's true that we loose some control but the gain is that
we do
not need to manage the versions of artifacts they manage.
Have I ever minimized the gain for WAR/EAR modules?
You claim that there are modules where it is harmful. But which ones?
In
I've told you already: it *has been* harmful in rest-tests module. Now
of course we haven't stopped working because master was failing and we
did what was required to fix the issue.
ptrans, it is harmless, IMO (no dependency -> no problem). In
rest-tests, you probably keep WF BoM included anyway, so removing the WF
BoM include from HK Parent does not change anything. Is there any other
module where the WF BoM include in Parent causes a problem?
Peter, I've been explaining the issue multiple times, and you're asking
me the same question again.
So maybe you don't read your emails with enough attention. Or you just
don't feel like something discussed here, on IRC and in meetings can be
merged in the parent POM.
7:26 a.m.
So wait a minute.
The changed dependency "suddenly" broke your rest tests.
IMHO, that is good in a sense that you now know something new about being
deployed in another runtime environment (namely WF9) which metrics WILL BE
deployed into.
Can it be painful? Yes, we've all been through such things. Is it avoidable? I
don't think so.
The versions of the modules coming from the Hawkular parent are what Hawkular
as whole standardizes on. You should not care about where they actually come
from (and the fact that they come from WF bom is a good thing, btw).
If you open the door for individual modules having non-standard versions of
dependencies, you know where we're going to end up.
I feel your pain, but please - standardization is more important that
occasional troubles of a single component.
On Tuesday, July 21, 2015 08:35:33 Thomas Segismont wrote:
Le 20/07/2015 18:50, Peter Palaga a écrit :
> On 2015-07-20 17:06, Thomas Segismont wrote:
> I can follow how hard it was to resolve the issue caused by WF BoM. But
> anyway, even if WF BoM was not imported in HK parent, are you not going
> to keep using the resteasy managed by WF BoM in rest-tests through
> keeping it imported somewhere in the rest-tests pom hierarchy?
>
> You maybe prefer to manage the resteasy client version yourself? -
> because otherwise, I do not see how not having WF BoM imported in HK
> parent would improve something important for you.
Exactly, managing it manually, because we just want to consume RESTEasy
client in a pure itest module.
> Yes, that's true that we loose some control but the gain is that we do
> not need to manage the versions of artifacts they manage.
Have I ever minimized the gain for WAR/EAR modules?
> You claim that there are modules where it is harmful. But which ones? In
I've told you already: it *has been* harmful in rest-tests module. Now
of course we haven't stopped working because master was failing and we
did what was required to fix the issue.
> ptrans, it is harmless, IMO (no dependency -> no problem). In
> rest-tests, you probably keep WF BoM included anyway, so removing the WF
> BoM include from HK Parent does not change anything. Is there any other
> module where the WF BoM include in Parent causes a problem?
Peter, I've been explaining the issue multiple times, and you're asking
me the same question again.
So maybe you don't read your emails with enough attention. Or you just
don't feel like something discussed here, on IRC and in meetings can be
merged in the parent POM.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:12 a.m.
Too much snark in this thread.
Is there a way that it can remain in the parent pom yet be
overridden/excluded as desired/required by metrics? Maven typically
prefers the locally decl over an inherited decl.
On 7/21/2015 8:44 AM, Heiko W.Rupp wrote:
On 21 Jul 2015, at 14:26, Lukas Krejci wrote:
> I feel your pain, but please - standardization is more important that
> occasional troubles of a single component.
+5
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:40 a.m.
Le 21/07/2015 15:12, Jay Shaughnessy a écrit :
Too much snark in this thread.
Is there a way that it can remain in the parent pom yet be
overridden/excluded as desired/required by metrics? Maven typically
prefers the locally decl over an inherited decl.
The only way you can "ignore" a BOM import is to re-declare it in your
component parent POM with a scope != import. Works until Maven team
decides "type=pom" + "scope=<yourchoice>" means something.
I was not inclined to do this given that the proper solution is easy to
implement.
2:57 p.m.
I'm inclined to support Thomas's suggestion. Because we typically deploy
to Wildfly I can understand why it was natural to suck the BOM up to
parent. But to give components some flexibility to control their own
imports without having to override the parent or possibly add
exclusions, it doesn't seem too bad to get the version of the BOM from
the parent and then import at the component level. And certainly it
makes sense if the BOM is just not needed by the Hawkular component.
Thomas has done the homework here. If someone is is absolutely 100%
against the change then we'll have to put it to a vote (or a flat out
decision from above), but I suggest we make the change and move
forward. If we learn downstream that it was better the other way then
I'm sure there will be enough groundswell to change it back.
Although, I think we can wait until after the next Hawkular release and
then a PR should be sent for all affected components that may need to
add the BOM dependency.
On 7/21/2015 11:40 AM, Thomas Segismont wrote:
Le 21/07/2015 15:12, Jay Shaughnessy a écrit :
> Too much snark in this thread.
>
> Is there a way that it can remain in the parent pom yet be
> overridden/excluded as desired/required by metrics? Maven typically
> prefers the locally decl over an inherited decl.
The only way you can "ignore" a BOM import is to re-declare it in your
component parent POM with a scope != import. Works until Maven team
decides "type=pom" + "scope=<yourchoice>" means something.
I was not inclined to do this given that the proper solution is easy to
implement.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:37 a.m.
Hi Thomas,
I was quite undecided about this change, but because it impacts all
consumers of Hawkular Parent (and implies some work in all consumers) I
hoped to hear about some specific module where the change is inevitable,
because the current state is dysfunctional due to the import of WF BoM.
You have not seem to have provided such one.
I am making my best to understand the background of your proposal. So to
paraphrase your position, the WF BoM import in Parent is not causing
anything bad directly, you just do not find it good that in non-WF
related modules (ptrans, REST tests) one may easily overlook that one
actually makes use of a version managed in WF BoM. When one is aware of
the fact that the given artifact is managed in WF BoM and one does not
want that, one is free to put one's own explicit version on the
dependency and the problem is solved (at least at the physical class
path level).
I agree that this "possibility to overlook" really exists, but I do not
think it is harmful enough to remove the WF BoM import from our Parent
BoM, mainly because the vast majority of our modules do target WF.
I agree that your proposal is in some sense cleaner, than what we have
now, but I do not think it is worth of the effort.
To name a situation where removing the WF BoM import would make sense
to me (Stefan asked about that): E.g. if we decided to target additional
platforms that support APIs conflicting with those of WF.
I prefer not to adopt this proposal, but I am far from being strongly
against it. Is there anybody else who wants to veto?
Thanks,
Peter
On 2015-07-21 21:57, Jay Shaughnessy wrote:
I'm inclined to support Thomas's suggestion. Because we typically deploy
to Wildfly I can understand why it was natural to suck the BOM up to
parent. But to give components some flexibility to control their own
imports without having to override the parent or possibly add
exclusions, it doesn't seem too bad to get the version of the BOM from
the parent and then import at the component level. And certainly it
makes sense if the BOM is just not needed by the Hawkular component.
Thomas has done the homework here. If someone is is absolutely 100%
against the change then we'll have to put it to a vote (or a flat out
decision from above), but I suggest we make the change and move
forward. If we learn downstream that it was better the other way then
I'm sure there will be enough groundswell to change it back.
Although, I think we can wait until after the next Hawkular release and
then a PR should be sent for all affected components that may need to
add the BOM dependency.
On 7/21/2015 11:40 AM, Thomas Segismont wrote:
> Le 21/07/2015 15:12, Jay Shaughnessy a écrit :
>> Too much snark in this thread.
>>
>> Is there a way that it can remain in the parent pom yet be
>> overridden/excluded as desired/required by metrics? Maven typically
>> prefers the locally decl over an inherited decl.
> The only way you can "ignore" a BOM import is to re-declare it in your
> component parent POM with a scope != import. Works until Maven team
> decides "type=pom" + "scope=<yourchoice>" means something.
>
> I was not inclined to do this given that the proper solution is easy to
> implement.
>
> _______________________________________________
> 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
11:51 a.m.
Hello Peter,
Hawkular Metrics needs this change as soon as possible (yesterday) since the project will
have two REST implementations targeting two different containers/standards. Work already
started so this change is late.
Thank you,
Stefan
----- Original Message -----
From: "Peter Palaga" <ppalaga(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Friday, July 24, 2015 11:37:11 AM
Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
Hi Thomas,
I was quite undecided about this change, but because it impacts all
consumers of Hawkular Parent (and implies some work in all consumers) I
hoped to hear about some specific module where the change is inevitable,
because the current state is dysfunctional due to the import of WF BoM.
You have not seem to have provided such one.
I am making my best to understand the background of your proposal. So to
paraphrase your position, the WF BoM import in Parent is not causing
anything bad directly, you just do not find it good that in non-WF
related modules (ptrans, REST tests) one may easily overlook that one
actually makes use of a version managed in WF BoM. When one is aware of
the fact that the given artifact is managed in WF BoM and one does not
want that, one is free to put one's own explicit version on the
dependency and the problem is solved (at least at the physical class
path level).
I agree that this "possibility to overlook" really exists, but I do not
think it is harmful enough to remove the WF BoM import from our Parent
BoM, mainly because the vast majority of our modules do target WF.
I agree that your proposal is in some sense cleaner, than what we have
now, but I do not think it is worth of the effort.
To name a situation where removing the WF BoM import would make sense
to me (Stefan asked about that): E.g. if we decided to target additional
platforms that support APIs conflicting with those of WF.
I prefer not to adopt this proposal, but I am far from being strongly
against it. Is there anybody else who wants to veto?
Thanks,
Peter
On 2015-07-21 21:57, Jay Shaughnessy wrote:
>
> I'm inclined to support Thomas's suggestion. Because we typically deploy
> to Wildfly I can understand why it was natural to suck the BOM up to
> parent. But to give components some flexibility to control their own
> imports without having to override the parent or possibly add
> exclusions, it doesn't seem too bad to get the version of the BOM from
> the parent and then import at the component level. And certainly it
> makes sense if the BOM is just not needed by the Hawkular component.
> Thomas has done the homework here. If someone is is absolutely 100%
> against the change then we'll have to put it to a vote (or a flat out
> decision from above), but I suggest we make the change and move
> forward. If we learn downstream that it was better the other way then
> I'm sure there will be enough groundswell to change it back.
>
> Although, I think we can wait until after the next Hawkular release and
> then a PR should be sent for all affected components that may need to
> add the BOM dependency.
>
>
> On 7/21/2015 11:40 AM, Thomas Segismont wrote:
>> Le 21/07/2015 15:12, Jay Shaughnessy a écrit :
>>> Too much snark in this thread.
>>>
>>> Is there a way that it can remain in the parent pom yet be
>>> overridden/excluded as desired/required by metrics? Maven typically
>>> prefers the locally decl over an inherited decl.
>> The only way you can "ignore" a BOM import is to re-declare it in
your
>> component parent POM with a scope != import. Works until Maven team
>> decides "type=pom" + "scope=<yourchoice>" means
something.
>>
>> I was not inclined to do this given that the proper solution is easy to
>> implement.
>>
>> _______________________________________________
>> 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
11:57 a.m.
Oh, why was that so complicated to hear a real reason :) Where can I see
the code if I may ask? -- P
On 2015-07-24 18:51, Stefan Negrea wrote:
Hello Peter,
Hawkular Metrics needs this change as soon as possible (yesterday) since the project will
have two REST implementations targeting two different containers/standards. Work already
started so this change is late.
Thank you,
Stefan
----- Original Message -----
> From: "Peter Palaga" <ppalaga(a)redhat.com>
> To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
> Sent: Friday, July 24, 2015 11:37:11 AM
> Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
>
> Hi Thomas,
>
> I was quite undecided about this change, but because it impacts all
> consumers of Hawkular Parent (and implies some work in all consumers) I
> hoped to hear about some specific module where the change is inevitable,
> because the current state is dysfunctional due to the import of WF BoM.
> You have not seem to have provided such one.
>
> I am making my best to understand the background of your proposal. So to
> paraphrase your position, the WF BoM import in Parent is not causing
> anything bad directly, you just do not find it good that in non-WF
> related modules (ptrans, REST tests) one may easily overlook that one
> actually makes use of a version managed in WF BoM. When one is aware of
> the fact that the given artifact is managed in WF BoM and one does not
> want that, one is free to put one's own explicit version on the
> dependency and the problem is solved (at least at the physical class
> path level).
>
> I agree that this "possibility to overlook" really exists, but I do not
> think it is harmful enough to remove the WF BoM import from our Parent
> BoM, mainly because the vast majority of our modules do target WF.
>
> I agree that your proposal is in some sense cleaner, than what we have
> now, but I do not think it is worth of the effort.
>
> To name a situation where removing the WF BoM import would make sense
> to me (Stefan asked about that): E.g. if we decided to target additional
> platforms that support APIs conflicting with those of WF.
>
> I prefer not to adopt this proposal, but I am far from being strongly
> against it. Is there anybody else who wants to veto?
>
> Thanks,
>
> Peter
>
>
> On 2015-07-21 21:57, Jay Shaughnessy wrote:
>>
>> I'm inclined to support Thomas's suggestion. Because we typically deploy
>> to Wildfly I can understand why it was natural to suck the BOM up to
>> parent. But to give components some flexibility to control their own
>> imports without having to override the parent or possibly add
>> exclusions, it doesn't seem too bad to get the version of the BOM from
>> the parent and then import at the component level. And certainly it
>> makes sense if the BOM is just not needed by the Hawkular component.
>> Thomas has done the homework here. If someone is is absolutely 100%
>> against the change then we'll have to put it to a vote (or a flat out
>> decision from above), but I suggest we make the change and move
>> forward. If we learn downstream that it was better the other way then
>> I'm sure there will be enough groundswell to change it back.
>>
>> Although, I think we can wait until after the next Hawkular release and
>> then a PR should be sent for all affected components that may need to
>> add the BOM dependency.
>>
>>
>> On 7/21/2015 11:40 AM, Thomas Segismont wrote:
>>> Le 21/07/2015 15:12, Jay Shaughnessy a écrit :
>>>> Too much snark in this thread.
>>>>
>>>> Is there a way that it can remain in the parent pom yet be
>>>> overridden/excluded as desired/required by metrics? Maven typically
>>>> prefers the locally decl over an inherited decl.
>>> The only way you can "ignore" a BOM import is to re-declare it in
your
>>> component parent POM with a scope != import. Works until Maven team
>>> decides "type=pom" + "scope=<yourchoice>" means
something.
>>>
>>> I was not inclined to do this given that the proper solution is easy to
>>> implement.
>>>
>>> _______________________________________________
>>> 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
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
12:07 p.m.
----- Original Message -----
From: "Peter Palaga" <ppalaga(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Friday, July 24, 2015 11:57:45 AM
Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
Oh, why was that so complicated to hear a real reason :) Where can I see
the code if I may ask? -- P
This is a developing story but here is the relevant main JIRA ticket:
https://issues.jboss.org/browse/HWKMETRICS-185
Thank you,
Stefan
On 2015-07-24 18:51, Stefan Negrea wrote:
> Hello Peter,
>
> Hawkular Metrics needs this change as soon as possible (yesterday) since
> the project will have two REST implementations targeting two different
> containers/standards. Work already started so this change is late.
>
>
> Thank you,
> Stefan
>
> ----- Original Message -----
>> From: "Peter Palaga" <ppalaga(a)redhat.com>
>> To: "Discussions around Hawkular development"
>> <hawkular-dev(a)lists.jboss.org>
>> Sent: Friday, July 24, 2015 11:37:11 AM
>> Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
>>
>> Hi Thomas,
>>
>> I was quite undecided about this change, but because it impacts all
>> consumers of Hawkular Parent (and implies some work in all consumers) I
>> hoped to hear about some specific module where the change is inevitable,
>> because the current state is dysfunctional due to the import of WF BoM.
>> You have not seem to have provided such one.
>>
>> I am making my best to understand the background of your proposal. So to
>> paraphrase your position, the WF BoM import in Parent is not causing
>> anything bad directly, you just do not find it good that in non-WF
>> related modules (ptrans, REST tests) one may easily overlook that one
>> actually makes use of a version managed in WF BoM. When one is aware of
>> the fact that the given artifact is managed in WF BoM and one does not
>> want that, one is free to put one's own explicit version on the
>> dependency and the problem is solved (at least at the physical class
>> path level).
>>
>> I agree that this "possibility to overlook" really exists, but I do
not
>> think it is harmful enough to remove the WF BoM import from our Parent
>> BoM, mainly because the vast majority of our modules do target WF.
>>
>> I agree that your proposal is in some sense cleaner, than what we have
>> now, but I do not think it is worth of the effort.
>>
>> To name a situation where removing the WF BoM import would make sense
>> to me (Stefan asked about that): E.g. if we decided to target additional
>> platforms that support APIs conflicting with those of WF.
>>
>> I prefer not to adopt this proposal, but I am far from being strongly
>> against it. Is there anybody else who wants to veto?
>>
>> Thanks,
>>
>> Peter
>>
>>
>> On 2015-07-21 21:57, Jay Shaughnessy wrote:
>>>
>>> I'm inclined to support Thomas's suggestion. Because we typically
deploy
>>> to Wildfly I can understand why it was natural to suck the BOM up to
>>> parent. But to give components some flexibility to control their own
>>> imports without having to override the parent or possibly add
>>> exclusions, it doesn't seem too bad to get the version of the BOM from
>>> the parent and then import at the component level. And certainly it
>>> makes sense if the BOM is just not needed by the Hawkular component.
>>> Thomas has done the homework here. If someone is is absolutely 100%
>>> against the change then we'll have to put it to a vote (or a flat out
>>> decision from above), but I suggest we make the change and move
>>> forward. If we learn downstream that it was better the other way then
>>> I'm sure there will be enough groundswell to change it back.
>>>
>>> Although, I think we can wait until after the next Hawkular release and
>>> then a PR should be sent for all affected components that may need to
>>> add the BOM dependency.
>>>
>>>
>>> On 7/21/2015 11:40 AM, Thomas Segismont wrote:
>>>> Le 21/07/2015 15:12, Jay Shaughnessy a écrit :
>>>>> Too much snark in this thread.
>>>>>
>>>>> Is there a way that it can remain in the parent pom yet be
>>>>> overridden/excluded as desired/required by metrics? Maven
typically
>>>>> prefers the locally decl over an inherited decl.
>>>> The only way you can "ignore" a BOM import is to re-declare it
in your
>>>> component parent POM with a scope != import. Works until Maven team
>>>> decides "type=pom" + "scope=<yourchoice>"
means something.
>>>>
>>>> I was not inclined to do this given that the proper solution is easy to
>>>> implement.
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
> _______________________________________________
> 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
12:11 p.m.
Le 24/07/2015 18:57, Peter Palaga a écrit :
Oh, why was that so complicated to hear a real reason
Yes, it looks awfully complicated to be heard, not to be said. From a
previous reply:
===
100% of components have at least one module to be deployed in Hawkular.
But then there are modules meant to run out of Hawkular
===
11:59 a.m.
Le 24/07/2015 18:37, Peter Palaga a écrit :
I was quite undecided about this change, but because it impacts all
consumers of Hawkular Parent (and implies some work in all consumers) I
hoped to hear about some specific module where the change is inevitable,
because the current state is dysfunctional due to the import of WF BoM.
You have not seem to have provided such one.
I told you already where the forced scopes were harmful.
Note that we could have vetoed the upgrade to parent version 16 because
applying it was breaking our build. See your PR, which I couldn't merge:
https://github.com/hawkular/hawkular-metrics/pull/260
But to keep things going, we've fixed the issue as we could, see my PR:
https://github.com/hawkular/hawkular-metrics/pull/268
I'll think about vetoing next time.
I am making my best to understand the background of your proposal. So to
paraphrase your position, the WF BoM import in Parent is not causing
anything bad directly, you just do not find it good that in non-WF
related modules (ptrans, REST tests) one may easily overlook that one
actually makes use of a version managed in WF BoM. When one is aware of
the fact that the given artifact is managed in WF BoM and one does not
want that, one is free to put one's own explicit version on the
dependency and the problem is solved (at least at the physical class
path level).
Already answered that. My position is I don't want to do this again.
I agree that your proposal is in some sense cleaner, than what we
have
now, but I do not think it is worth of the effort.
The effort is a few lines removed in the parent and re-added in the
components where relevant. We should be able to manage.
To name a situation where removing the WF BoM import would make
sense
to me (Stefan asked about that): E.g. if we decided to target additional
platforms that support APIs conflicting with those of WF.
Yes we'll soon need to do this in Metrics, for an EAP6.4 deployment.
Funny how the situation came up so quickly.
I prefer not to adopt this proposal, but I am far from being strongly
against it. Is there anybody else who wants to veto?
Read this sentence again. Then facepalm or ROFL.
10:35 a.m.
Le 21/07/2015 14:44, Heiko W.Rupp a écrit :
On 21 Jul 2015, at 14:26, Lukas Krejci wrote:
> I feel your pain, but please - standardization is more important that
> occasional troubles of a single component.
+5
I haven't asked for "de-standardization", I've asked for not forcing
Wildfly BOM artifacts versions and scopes in every single module we work
on, even unrelated to Wildfly. Epic fail.
I have put too much into this. Probably because *I talked about this
change a month ago*, sent a PR in the meantime. The PR was not merged
and back from a week of PTO, the PR closed, and a new parent POM
released. After taking the time to work with Wildfly team and clarify
with the them the intended usage of the BOM, I was quite upset. I'll get
over it.
2:22 a.m.
On 21 Jul 2015, at 17:35, Thomas Segismont wrote:
Le 21/07/2015 14:44, Heiko W.Rupp a écrit :
> On 21 Jul 2015, at 14:26, Lukas Krejci wrote:
>> I feel your pain, but please - standardization is more important that
>> occasional troubles of a single component.
>
> +5
with the them the intended usage of the BOM, I was quite upset. I'll
I did not want to upset you. What I wanted to convey with that quite
sparse "+5" comment is that we should all over Hawkular use the
same versions of stuff as it will lessen the maintenance burden.
9:31 a.m.
Le 21/07/2015 14:26, Lukas Krejci a écrit :
So wait a minute.
The changed dependency "suddenly" broke your rest tests.
IMHO, that is good in a sense that you now know something new about being
deployed in another runtime environment (namely WF9) which metrics WILL BE
deployed into.
rest-tests module will never be deployed into Wildfly.
Can it be painful? Yes, we've all been through such things. Is it
avoidable? I
don't think so.
Yes *it is* avoidable. Don't force dependency versions and scopes for
non WAR/EAR modules. Simply declare the BOM version in the parent, and
import the BOM in WAR/EAR modules to be deployed to Hawkular.
The versions of the modules coming from the Hawkular parent are what Hawkular
as whole standardizes on. You should not care about where they actually come
from (and the fact that they come from WF bom is a good thing, btw).
If you open the door for individual modules having non-standard versions of
dependencies, you know where we're going to end up.
I feel your pain, but please - standardization is more important that
occasional troubles of a single component.
I've *never* suggested to drop usage of the BOM for WAR/EAR modules to
be deployed to Hawkular (that is, to Wildfly).
In fact, if you look at git history, you'll notice *I* removed the
manual dependency declarations in the metrics WAR project in order to
use the Wildfly BOM.
It was quite some time ago, when there was no Hawkular org and Metrics
was called rhq-metrics. Then it was later factored out to the parent,
which is a good thing, with respect to BOM version enforcement.
3447
days inactive
3479
days old
27 comments
7 participants
participants (7)
-
Heiko W.Rupp -
Jay Shaughnessy -
John Mazzitelli -
Lukas Krejci -
Peter Palaga -
Stefan Negrea -
Thomas Segismont