[Hawkular-dev] Parent POM and Wildfly BOM

[Stefan Negrea]

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
>