[Hawkular-dev] Parent POM and Wildfly BOM

[Peter Palaga]

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
>