Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider splitting up test namespaces into another project? #197

Open
vincentjames501 opened this issue Sep 19, 2019 · 3 comments
Open

Consider splitting up test namespaces into another project? #197

vincentjames501 opened this issue Sep 19, 2019 · 3 comments

Comments

@vincentjames501
Copy link

When we included jackdaw in our project our uberjar size grew about ~20-30mb (most of that is Kafka libs of course). jackdaw is bringing in aleph and transitively manifold which appears to only really be used in the test related namespaces (the admin namespace uses manifold in a few spots which seem easy to remove) increasing our jar ~5MB. It would be nice to bring in a dependency like [fundingcircle/jackdaw-test "0.6.8"] instead? I can of course exclude these dependencies which I have, just a thought!

@cddr
Copy link
Contributor

cddr commented Sep 20, 2019

It was suggested when we began the project that the test component could be housed elsewhere. However, there was quite a strong desire for jackdaw to include tools that could be used for testing as well as implementing a kafka based system.

As you've noted, manifold is also used by the admin ns which fuzzes the issue slightly as there are now 2 top-level namespaces that would break if you exclude aleph when depending on jackdaw (i.e. jackdaw.admin and jackdaw.test). Not sure it would be that easy to remove though for someone who doesn't know the underlying Java primitives that well :-)

I think if anything, there's some useful async code under the test namespace that should probably be slightly refactored and moved into a non-test namespace and made available for folks that want to use the kafka client in an asynchronous fashion.

@AndreaCrotti
Copy link
Contributor

+1 on this, but manifold is not a massive issue, the problem is more that aleph brings in netty as well.
This could be particularly annoying if you already use a different version of Netty in your application.

Aleph could still be an optional dependency and the test machine could maybe only work if that's available?
Moving it out might be better but it's not really the only possibility.

@AndreaCrotti
Copy link
Contributor

From this simple attempt #360
just doing that change makes a 4MB difference in the produced jar, but well more importantly it doesn't include netty anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants