threatgrid / naga

Datalog based rules engine
Eclipse Public License 1.0
379 stars 19 forks source link

Tidy up deps further by splitting out an uberjar profile #134

Closed RickMoynihan closed 3 years ago

RickMoynihan commented 3 years ago

Naga is both an app and a library, so move app deps into uberjar & dev profiles.

Also:

  1. enable AOT in uberjar (not sure you need to disable this now for uberjar CLI users)
  2. prevent profiles from contaminating classpath with :target-path (should mitigate against needing to ^:skip-aot)
  3. dropped exclusion on google.guava in uberjar profile (as it appears to be required for the uberjar now)

You could possibly go further by moving naga.cli into a separate source path that is only included in the uberjar profile (as library users probably don't require this namespace). I didn't do this though as it then opens up more complex questions about where the datomic/asami storage backends should live e.g. separate deps etc, however ultimately I expect you don't want to introduce more dependencies at this stage.

Unfortunately because of the transitive dependency on zuko through asami you still seem to be bringing in cheshire transitivly, which then brings in the dreaded jackson. If we know library users won't call a path that depends on this we could add an :exclusion for it.

Anyway just a speculative PR as you'd spent some time tidying the deps, I thought I'd see if we could improve it further. I'm not 100% sure of your workflows etc though so it's possible this isn't an improvement or worth it.

Thanks again!

quoll commented 3 years ago

Thanks for this PR. I haven't used it directly, but it prompted me into extracting the CLI into a sub-project found in the cli directory.

The uberjar in the CLI subproject is fully AOT and includes all dependencies. There was also no need to separate some of the elements (like Datomic) into the :dev profile.

Cheshire is needed locally for 2 things: