----- Original Message ----- > From: "Peter Palaga" <ppalaga(a)redhat.com&gt; > To: hawkular-dev(a)lists.jboss.org > Sent: Tuesday, November 24, 2015 4:26:07 PM > Subject: [Hawkular-dev] Proposal: introduce DependencyConvergence enforcer rule > > Hi *, > > The proposal is to introduce an enforcer plugin rule called > DependencyConvergence to hawkular-parent. From the rule's docs [1]: > > > This rule requires that dependency version numbers converge. If a > > project has two dependencies, A and B, both depending on the same > > artifact, C, this rule will fail the build if A depends on a > > different version of C then the version of C depended on by B. > > Why do we need this: because it brings more consistency and better > control during the productization and sustaining of the project. > > Known pitfalls - see [2] > > Any comments on this? > I think this rule may bring more complexity in some projects. Metrics should depend of Wildfly and EAP64 versions, so it is possible that in some controlled scenario a project might depends on a different version.

Also I'm having a similar scenario for ISPN in alerts too, so I vote to not add this rule for now.

> Thanks, > > Peter > > [1] > http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html > [2] http://stackoverflow.com/a/16239482 > _______________________________________________ > 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

From a Productization perspective, dependency convergence is super important. Consider this hypothetical(names and severity changed to protect the innocent...) issue.

From: "Lucas Ponce" <lponce(a)redhat.com&gt; To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Tuesday, November 24, 2015 11:16:01 AM Subject: Re: [Hawkular-dev] Proposal: introduce DependencyConvergence enforcer rule ----- Original Message ----- > From: "Peter Palaga" <ppalaga(a)redhat.com&gt; > To: "Discussions around Hawkular development" > <hawkular-dev(a)lists.jboss.org&gt; > Sent: Tuesday, November 24, 2015 5:05:30 PM > Subject: Re: [Hawkular-dev] Proposal: introduce DependencyConvergence > enforcer rule > > Hi Lucas, inline... > > On 2015-11-24 16:36, Lucas Ponce wrote: > > > > > > ----- Original Message ----- > >> From: "Peter Palaga" <ppalaga(a)redhat.com&gt; > >> To: hawkular-dev(a)lists.jboss.org > >> Sent: Tuesday, November 24, 2015 4:26:07 PM > >> Subject: [Hawkular-dev] Proposal: introduce DependencyConvergence > >> enforcer > >> rule > >> > >> Hi *, > >> > >> The proposal is to introduce an enforcer plugin rule called > >> DependencyConvergence to hawkular-parent. From the rule's docs [1]: > >> > >> > This rule requires that dependency version numbers converge. If a > >> > project has two dependencies, A and B, both depending on the same > >> > artifact, C, this rule will fail the build if A depends on a > >> > different version of C then the version of C depended on by B. > >> > >> Why do we need this: because it brings more consistency and better > >> control during the productization and sustaining of the project. > >> > >> Known pitfalls - see [2] > >> > >> Any comments on this? > >> > > > > I think this rule may bring more complexity in some projects. > > > > Metrics should depend of Wildfly and EAP64 versions, so it is possible > > that > > in some controlled scenario a project might depends on a different > > version. > > I do not think that the DependencyConvergence would have a problem with > Metrics building with Wildfly and EAP64 because those two are used as > dependencies in separate profiles and (correct me if I am wrong) those > two profiles make up two independent dependency hierarchies. Those two > dependency hierarchies need to be internally consistent too, e.g. libs > from WF x may not be mixed with libs from EAP y. DependencyConvergence > should ensure that and that's definitely a good thing. > > > Also I'm having a similar scenario for ISPN in alerts too, so I vote to > > not > > add this rule for now. > > So you have two ISPN versions in two independent profiles? > Yes, versions are separated on profiles. If having different versions of the same library but in different profile is ok for this plugin then I don't have major inconvenience to use it. My fear is to spend more time on the pom.xml than necessary/reasonable dealing with potential exceptions. > -- P > > >> Thanks, > >> > >> Peter > >> > >> [1] > >> http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html > >> [2] http://stackoverflow.com/a/16239482 > >> _______________________________________________ > >> 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

I'm fine with adding the rule as long as it's possible to deactivate it at the module level if needed (with serious justification).

Le 24/11/2015 23:06, Simeon Pinder a écrit : > >From a Productization perspective, dependency convergence is super important. Consider this hypothetical(names and severity changed to protect the innocent...) issue. > > 1)Talon libraries are productized and delivered to customers for 1.0 and 2.0. Yay! > 2)A nasty exploit, CVE(Common Vulnerability & Exposure), is detected in Talon 2.x(or one of the libraries it depends upon), that affects all versions of said library > before version 2.0.1. > 3)The fix for existing customers/servers must be applied or anyone with a web browser can take down or "own" said live servers. Happens more than you think... > > All of this is horrible and after many hours of work we figure out that by patching a single jar to "old-plus-newly-secure-code" version will help bring customers back to a > safe operating environment. > > With a single affected jar we must now: > i)finding all jar instances, less that 2.0.1, that we have delivered to customers in a product version > ii)build "old-plus-newly-secure-code" version or migrate to newer version if you're lucky enough that such a thing exists. > iii)retest all current functionality a.k.a push back through regression suites and formally back through QE. > iv)deliver said patch and 'hope' that customers actually apply the fix before a compromised Talon instance puts them on the news because of said exploit. > > Steps i-iv are an abridged description of an easier path to a fix. Without dependency convergence we can now expect to a) rebuild/patch the remaining N-1 affected versions > b)for all(1.0,1.x,2.0,2.x,etc.) Talon versions that have been released all the while regretting that we hadn't converged on shared version. Sure we hope that the single jar fix works > the same across all affected versions and that the customer is on the latest version, but Murphy's Law implies otherwise. > > In short, converging dependency versions wherever possible, is almost a must. Annoying now, but so much more painful when there actually is a problem that has to be fixed. > And yes I've seen this scenario actually play out several times in the last few years. It's extra product release, security, qe and support work all around. > > With all that being said, as a counter point, many dependencies span many scopes(test as well), so we should also make sure that there is a way to disable said strict dependency > convergence in the event that only the "test suite" has an issue with the new library version. Looks like the right settings in a profile would be enough but the devil's in > the details. > > -Simeon > > ----- Original Message ----- >> From: "Lucas Ponce" <lponce(a)redhat.com&gt; >> To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, November 24, 2015 11:16:01 AM >> Subject: Re: [Hawkular-dev] Proposal: introduce DependencyConvergence enforcer rule >> >> >> >> ----- Original Message ----- >>> From: "Peter Palaga" <ppalaga(a)redhat.com&gt; >>> To: "Discussions around Hawkular development" >>> <hawkular-dev(a)lists.jboss.org&gt; >>> Sent: Tuesday, November 24, 2015 5:05:30 PM >>> Subject: Re: [Hawkular-dev] Proposal: introduce DependencyConvergence >>> enforcer rule >>> >>> Hi Lucas, inline... >>> >>> On 2015-11-24 16:36, Lucas Ponce wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Peter Palaga" <ppalaga(a)redhat.com&gt; >>>>> To: hawkular-dev(a)lists.jboss.org >>>>> Sent: Tuesday, November 24, 2015 4:26:07 PM >>>>> Subject: [Hawkular-dev] Proposal: introduce DependencyConvergence >>>>> enforcer >>>>> rule >>>>> >>>>> Hi *, >>>>> >>>>> The proposal is to introduce an enforcer plugin rule called >>>>> DependencyConvergence to hawkular-parent. From the rule's docs [1]: >>>>> >>>>> > This rule requires that dependency version numbers converge. If a >>>>> > project has two dependencies, A and B, both depending on the same >>>>> > artifact, C, this rule will fail the build if A depends on a >>>>> > different version of C then the version of C depended on by B. >>>>> >>>>> Why do we need this: because it brings more consistency and better >>>>> control during the productization and sustaining of the project. >>>>> >>>>> Known pitfalls - see [2] >>>>> >>>>> Any comments on this? >>>>> >>>> >>>> I think this rule may bring more complexity in some projects. >>>> >>>> Metrics should depend of Wildfly and EAP64 versions, so it is possible >>>> that >>>> in some controlled scenario a project might depends on a different >>>> version. >>> >>> I do not think that the DependencyConvergence would have a problem with >>> Metrics building with Wildfly and EAP64 because those two are used as >>> dependencies in separate profiles and (correct me if I am wrong) those >>> two profiles make up two independent dependency hierarchies. Those two >>> dependency hierarchies need to be internally consistent too, e.g. libs >>> from WF x may not be mixed with libs from EAP y. DependencyConvergence >>> should ensure that and that's definitely a good thing. >>> >>>> Also I'm having a similar scenario for ISPN in alerts too, so I vote to >>>> not >>>> add this rule for now. >>> >>> So you have two ISPN versions in two independent profiles? >>> >> >> Yes, versions are separated on profiles. >> >> If having different versions of the same library but in different profile is >> ok for this plugin then I don't have major inconvenience to use it. >> >> My fear is to spend more time on the pom.xml than necessary/reasonable >> dealing with potential exceptions. >> >>> -- P >>> >>>>> Thanks, >>>>> >>>>> Peter >>>>> >>>>> [1] >>>>> http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html >>>>> [2] http://stackoverflow.com/a/16239482 >>>>> _______________________________________________ >>>>> 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 >> > _______________________________________________ > 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

Any comments on this?

On 24.11.2015 16:26, Peter Palaga wrote: > Any comments on this? Do you have any reports for how big would be the impact once it's introduced?

For me, I prefer to have this implemented now than to deal with this tech debt in the future. - Juca. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev