Code-based exclusions

[Neacsu Bogdan <pi...@yahoo.com.INVALID>]

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

Re: Code-based exclusions

[Tibor Digana <ti...@apache.org>]

Sorry but this is absolute nonsense. It is only and only a problem with
people and not the tools. The tools actually MUST NOT make any assumptions
about your code, platform and abstractions.
This is a typical issue in the entire project, technologies craftmanship of
developers in POM of provided dependencies and POM of consumers/project.
Maven already has all these options in pom.xml called 'scope' and
'optional'. There are practices with BOM which may help in project design
as well, and then the rest is a bunch of experiences and a level of
expertise.
Nobody can guarantee that doing the project design twice with two people
would end up with identical result but what can be said is that a good
project designer would design the project always better than anyone else.

Try to exclude expected dependencies in your configuration of the
obfuscation tool and include original jars using the maven-shade-plugin, or
do not use Spring and use application servers ;-)
Building very complicated Uber file like yours would be hardly
maintainable. Better to skip doing this if possible.

Good luck,
Tibor


On Fri, Jun 29, 2018 at 4:59 PM, Neacsu Bogdan <piramyd_on@yahoo.com.invalid
> 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
>

Re: Code-based exclusions

[Paul Hammant <pa...@hammant.org>]

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 <piramyd_on@yahoo.com.invalid
> 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.