An example would be using Hibernate - it has code for MySql, Postgres, SqlServer, Oracle (etc). In one particular deployment at one particular time, a so-using compan is pretty sure that it is (say) Postgres for now. Google do leave out (*exclude*) unused packages/classes from deployments. At least from third party jars. For in-house stuff their use of Blaze (Bazel) means that they never *include t*he sub-packages that are not pertinent to the build target. Blaze is a directed graph build tool.
Shade (and its Maven plugin) is a tool that COULD leave out code that's not used. How to calculate that for a recursive build tech like Maven? Why after test runs and code-coverage maps of course. So someone has to code that. I for one would welcome it. Caveat: I left Google in Jan of 2009 - https://mike-bland.com/2012/07/10/test-mercenaries.html One more thing - I'm advocating bytecode instrumentation, whereas you were talking source code parsing. Mine is 100x easier to get perfect - sorry! - Paul On Fri, Jun 29, 2018 at 7:59 AM, Neacsu Bogdan <[email protected] > wrote: > Hello, > > Recently, I was thinking at a pretty nice feature that would make the grat > maven tool an awesome one: code-based exclusions. > Why should this be needed? Because some libs have dependencies of their > own, that are not really used by the final code. > In theory, one should be able to create a maven option, to exclude all the > imported jars that simply aren't really used in the project. > This means that maven should be able to have a plugin that parses the > code, searches in depth what libraries are indeed used by this code (and > what libraries are used by those libraries etc.), and what are not, and > should automatically add excludes for the unused ones. > The only three problems I see with this implementation right now are:- > obfuscated libs;- signed libs;- libs that use reflections to load classes > (like spring). > Does anybody know if this should be possible? > > Thanks,Bogdan Neacsu > -- Paul Hammant DevOps <https://devops.paulhammant.com> Let me give your enterprise a step by step plan to migrate from GitFlow (or worse) to high-throughput CD on the essential DevOps foundation: Trunk-Based Development.
