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

Avoid external lib deps in util #11

Open
c0c0n3 opened this issue Aug 9, 2017 · 1 comment
Open

Avoid external lib deps in util #11

c0c0n3 opened this issue Aug 9, 2017 · 1 comment

Comments

@c0c0n3
Copy link
Member

c0c0n3 commented Aug 9, 2017

Currently util depends on a handful of external libs but those dependencies are only needed for extra functionality (Spring & servlet utils, Yaml serialisation) that's only used in Smuggler. The new kew* projects don't use any of those libs and the soon-to-be-implemented rendering micro service (#8) won't need them either. To avoid the extra jars being added to the kew project's runtime, I'm using a non-transitive dependency on util in the kew build file. So we could take the stance that util can depend on external libs and any project that uses a util class depending on an external lib, should add that lib to its classpath. But it may be cleaner to move util classes that depend on external libs to separate projects so we could have:

  • util-spring: new project containing the classes currently in util.spring. This project will have an external dep on Spring-Web.
  • util-serialization: new project with the util.config.YamlConverter class as well as all the classes currently in ome.smuggler.providers.json. This project will depend on Snake Yaml and Gson.
  • util: all the remaining classes. These only depend on the SDK and EE libs (javax.servlet)

The downside is that we'd have even more projects with just a handful of classes in them. Not sure which approach is best. Comment if you have any preferences!

@c0c0n3
Copy link
Member Author

c0c0n3 commented Feb 4, 2018

Serialization

While we decide on what to do with the dependency issues above, I moved JSON/YAML serialisation out of the server component into util---see PR #16.

The new classes sit in the util.serialization package and can be reused by other components---I've done this since I'll need serialisation functionality for the rendering micro-service. If we decide to have a separate util-serialization project, all we need to do is move the whole package across to the new project and remove the Snake Yaml and Gson dependencies from util.gradle.

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

1 participant