Re: Code-based exclusions

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

Re: Code-based exclusions

Tibor Digana
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 <[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
>