ant - Extract a reference graph while compiling Java codebase? -
background:
- i'm working (for me) reasonably large codebase (eg: i've got few of related projects checked out @ moment, , > 11000 classes).
- build ant, tests junit, ci jenkins.
- running tests before checkin not option, takes jenkins hours. of individual apps can 45 minutes.
- there tests don't reference individual methods based on reflection, , in cases don't directly reference class of tested methods, interrogate aggregator class, , aware of patterns of pass-through methods in use here. it's big codebase, > 10 developers, , i'm not in charge, this can not change now.
what want, ability before check-in print out list of test classes 2 degrees away (kevin-bacon-wise) class in git diff list. way can run them , cut down on angry emails jenkins when missed gets run , has error.
the easiest way can think of achieve code myself ruby script or similar, allows me account of patterns we're using, need able query "which classes reference class x?"
i parse .java or (easier) .class files info, i'd rather not :) there way can make javac export in simple format compiles?
is there way can make javac export in simple format compiles?
afaik, no.
however, there other ways list of dependencies:
(note unlikely static tool extract dependencies resulting class.forname()
, etcetera. note cannot infer complete set of dependencies bytecode files because of way "compile time constants" handled.)
it strikes me there few problems here:
it sounds me build, , indeed project structure monolithic. if restructure code base large-scale modules build separately (according dependencies), , version controlled separately, need full build , run unit tests when there change high ... in module else depends on. (can suggest "maven" word. helps large codebase, , 11,000 classes large.)
it sounds may suffering "branches hard" problem of classic vcs systems.
it sounds may need beefier ci system. if you've got more cores , build framework right, should able faster ci builds. (and if modularize rebuild less ...)
i think might easier address slow build/test cycle way rather via (possibly bespoke) tooling dependency analysis.
but recognize may not make decisions.
Comments
Post a Comment