I agree that dependency insanity could cause problems , as well as resources.
However, the maven dependencies can be partly resolved because we can also just analyze the pom to look at those dependencies. I imagine as long as resources are loaded from /src/test/resources then we can make ANY change here trigger a full re-test. It’s not like this happens often. And in spare CPU time you can re-run FULL tests (and maybe we should do this before a release). But at least this way, if something DEFINITELY fails, you can resolve it somewhat quickly. On Wed, Feb 11, 2015 at 4:52 AM, Ron Wheeler <rwhee...@artifact-software.com > wrote: > How do you manage/allow dependency changes? > If you are using a parent pom with a dependency management section, you > have a single pom to watch. > > We adopted a policy that developers are not able to change dependencies > during a release cycle. > The versions of dependencies are a team decision under the direct control > of the project manager and a meeting is held at the beginning of the > release cycle to review the dependencies and settle on a stable set. > Of course, there are emergencies from time to time but the decision to > change is a team decision. > > This increase the stability of the development environment and makes the > testing of upgraded dependencies happen at the start of the release cycle > so that we know at the start that the initial code still works with > upgraded dependencies. > > Nothing is worse or more time-consuming that have a test failure appear in > the midst of your changing code but caused by a dependency change. > > A developer will go crazy trying to figure out why a small change to their > code caused such a problem. > > I am not sure how you can be sure that a change in a transitive dependency > will not cause errors higher up in the stack or create bad data structures > that only show up later in code that has no dependency on the original > culprit. > > Ron > > > > On 11/02/2015 2:57 AM, Andreas Gudian wrote: > >> Hi, >> >> You can't do that with javac, but the takari-plugins maintain a fine >> grained dependency graph in order to do incremental builds. >> >> With tests, it is a different thing, though. Their runtime behaviour may >> depend on more than their class dependency might tell you: property/xml >> files, dependency injection - stuff like that. >> I think clover (code coverage tool for test) has a feature to run only >> tests for which any code has changed that has been recorded to be used in >> the previous run. >> >> So for real incremental tests out of the box, we'd have to support >> different strategies: compile-time dependencies, resource dependencies, >> runtime dependencies. That's quite an undertaking. For Surefire 3 we want >> to open up the API to allow attaching stuff like that from the outside. >> >> Andreas >> >> Am Mittwoch, 11. Februar 2015 schrieb Kevin Burton : >> >> Is there an easy way to build the Java dependency tree from the compiler? >>> >>> I was thinking that if you can get the Java dependency tree built, then >>> you >>> take take a look at a diff and look at which files have changed. >>> >>> Then from there you could take say 1000 test and reduce that to only 10 >>> test if only those ten had their dependencies changed. >>> >>> The theory being that if the previous commit already tested the previous >>> 990, why test them again? >>> >>> The epiphany I had was that one could EASILY integrate this into maven by >>> just passing a list of which tests to skip. >>> >>> This could dramatically improve the speed of continuous integration >>> systems >>> >>> -- >>> >>> Founder/CEO Spinn3r.com >>> Location: *San Francisco, CA* >>> blog: http://burtonator.wordpress.com >>> … or check out my Google+ profile >>> <https://plus.google.com/102718274791889610666/posts> >>> <http://spinn3r.com> >>> >>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile <https://plus.google.com/102718274791889610666/posts> <http://spinn3r.com>
