Code-based exclusions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Code-based exclusions

Neacsu Bogdan
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
Reply | Threaded
Open this post in threaded view
|

Re: Code-based exclusions

Paul Hammant
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 <[hidden email]
> 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.