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