[Hawkular-dev] Proposal: introduce DependencyConvergence enforcer rule

[Simeon Pinder]

>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
>