bastion-dev / Bastion

Java test library for HTTP APIs
http://bastion.rocks
GNU General Public License v3.0
13 stars 8 forks source link

Reduce the number of dependencies in Bastion #57

Open KPull opened 7 years ago

KPull commented 7 years ago

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.

KPull commented 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.

KPull commented 7 years ago

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).

KPull commented 7 years ago

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.