just my 2 cents. For version clash of artifacts you can use dependency:analyze-duplicates of the maven-dependency plugin. Maybe of help would be https://github.com/ning/maven-duplicate-finder-plugin which checks on a per-class base.
Robert Am 07.03.2013 um 15:35 schrieb Andrew Petro <ape...@unicon.net>: > I agree. > > 1) Dependency changes should be accomplished through a Pull Request with > review, and that > 2) part of that review should be a mvn notice:check, and that > 3) the pull request should address licensing issues before merge > > I love your best case idea of checking for dependency multi-version in > resulting packaged artifacts and in plausible maven overlays. I agree that > would be obnoxious to do manually; I suspect that the check could be > automated but have no direct experience doing so. > > I agree with the general ethos of tightening up work at pull request time > before merge so as to reduce technical debt paid by release managers. > > > On Thu, Mar 7, 2013 at 6:59 AM, Marvin Addison <marvin.addi...@gmail.com> > wrote: > We need a policy on bumping dependency versions. We've had a number of > issues lately related to transitive dependencies causing problems or > interactions between modules. We need some additional tools to vet > dependency changes, and the developer responsible for the change needs > to address licensing issues in the commit. The latter part has fallen > on me at release time and it's been a substantial time sink (not to > mention hassle). We need to tighten up on dependencies generally. > > At a minimum, I'd like to get agreement that a dependency change is > followed by mvn notice:check from the project root to ensure passage, > and any licensing issues are addressed in the same change set. > > Recommendations for tools/processes to detect dependency issues? Best > case would be to ensure that there is exactly one version of a > dependency in each packaged artifact, and that an overlay WAR built > from every combination of modules (or at least popular ones) has > exactly one version. The latter sounds time consuming at face value, > but worth the effort to deployers. > > M > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: ape...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > robertoschw...@googlemail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
