[Hawkular-dev] Proposal: introduce DependencyConvergence enforcer rule

Wed Nov 25 03:18:05 EST 2015

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 at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Tuesday, November 24, 2015 11:16:01 AM
>> Subject: Re: [Hawkular-dev] Proposal: introduce DependencyConvergence enforcer rule
>>
>>
>>
>> ----- Original Message -----
>>> From: "Peter Palaga" <ppalaga at redhat.com>
>>> To: "Discussions around Hawkular development"
>>> <hawkular-dev at lists.jboss.org>
>>> 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 at redhat.com>
>>>>> To: hawkular-dev at 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 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
>