[Hawkular-dev] Proposal: introduce DependencyConvergence enforcer rule

Peter Palaga ppalaga at redhat.com
Wed Nov 25 04:04:16 EST 2015 

On 2015-11-25 09:18, Thomas Segismont wrote:
> 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).

I am frankly failing to conceive of an acceptable justification to 
disable the rule for some module.

I think that the only legal way to fix any violations of the rule should 
be to exclude one of the conflicting artifacts (with all the known 
pitfalls - see http://stackoverflow.com/a/16239482 )

-- P

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

More information about the hawkular-dev mailing list