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>
To: "Discussions around Hawkular development"
<hawkular-dev(a)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(a)redhat.com>
> To: "Discussions around Hawkular development"
> <hawkular-dev(a)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(a)redhat.com>
> >> 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