[Hawkular-dev] Parent POM and Wildfly BOM

[Peter Palaga]

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 at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>