Open KPull opened 7 years ago
Perhaps we could also get rid of the AssertJ dependency if we rewrite our Assertions objects so that they don't use AssertJ internally.
Another alternative for fixing this issue is by using something like the maven-shard-plugin
(https://maven.apache.org/plugins/maven-shade-plugin/index.html). It creates an Uber-Jar file containing all the dependency classes needed by Bastion. The Bastion Jar file itself will then have no other dependencies.
I think is a good idea because we could keep using features such as the AssertJ library without having to duplicate the code in that library. It also keeps the Bastion library self-contained as possible as it won't need additional dependencies. Finally, it also fixes the version of libraries in use by a particular Bastion version: if a user uses their own version of AssertJ, for example, Bastion will still use the one that was originally compiled with it (therefore less version conflict bugs).
Another target for the maven-shade-plugin
would be copying the DefaultResourceLoader
class from Spring Framework Core. Right now, we're depending on the entire Spring Framework Core library just for this class. With the plugin we would copy the bytecode over into Bastion directly, remove the dependency and avoid duplicating code unnecessarily.
Right now, Bastion has too many dependencies which are not necessarily used by the average user. In particular, I can see two dependencies which we can start with:
These libraries should be optional dependencies. The user should include them in their own POM file if they are going to use these features in Bastion.