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: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
