[bug] external classes embedded in jcasbin's distribution jar

[tpsb]

With the introduction of CLI (v1.57.0) the project now uses shade plugin and includes some of the dependencies in the built jar.
When using jcasbin as a library in a project where no CLI is needed this introduces certain issues:

• the project might want to use a different version of a library than the one included in the jar and depending where the jars end up on the classpath, invalid classes might get used,
• having some of the libraries included directly in casbin's jar obscures proper dependency management and analysis.

In my specific case the problem surfaced as I use a newer version of slf4j-api and use some of the newly introduced APIs that the version of slf4j included in the jcasbin's jar does not have, and it happens that jcasbin's jar comes before the proper slf4j-api jar on the classpath and incorrect versions of classes are resolved resulting in failed compilations.

central.sonatype.com shows that between version 1.55.0 and 1.63.0 the number of dependencies fell by 10 so I'd assume that classes from 10 external jars get now embedded in jcasbin's jar.

I don't think the library jar should include any non-project specific classes. Please consider creating a separate CLI specific distribution that would embed the necessary dependencies and keep the library jar clean of external dependencies being embedded in.

[casbin-bot]

@tangyang9464 @imp2002

[hsluoyz]

@tpsb can you check which release (aka pull request) causes the issue you mentioned? https://github.com/casbin/jcasbin/releases

Even if we have no Maven registry release for some recent versions, you can still git clone that revision and build the jar by yourself to check

[tpsb]

it's tag v1.57.0 which corresponds to PR#402

[hsluoyz]

@tpsb PR: #402 has been reverted: d2e2f78