[Hawkular-dev] Parent POM and Wildfly BOM

[Stefan Negrea]

----- 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: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 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
> >
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>