JasperFx Ecosystem Dependency Reorganization

[jeremydmiller]

This is in Wolverine just because it needs to go somewhere, and because Wolverine is kind of at the top.

"Problems"

• There are some shared framework-y elements like the application assembly determination that are duplicated between Marten & Wolverine today, with Ermine coming soon-ish
• I think it would be hugely advantageous to have some sharing of the OptimizeArtifictWorkflow between Marten & Wolverine, just so there's less repetitive junk going on in bootstrapping -- especially when there are becoming some many different things that should or could be different in Development vs Production mode
• Wolverine 3.0 is coming soon, so Wolverine can accommodate breaking changes, but there's no other justification for a Marten 8 in the immediate future. At least until Ermine later this year
• Lamar is already on the chopping block. Questioning whether Oakton should be as well

Today

Some of the current dependencies between the greater JasperFx / Critter Stack world:

I've omitted Weasel, but it's of course there and would be impacted by this too.

Proposed Future

Okay, so this is going to require a full point Marten 8 and a new Wolverine as well. Maybe this doesn't exactly happen until Wolverine 4. Might help to start with some temporary [Obsolete] tags in especially Marten

Here's the big points, I think:

• The basic goal is to simplify the dependency structure and just make it look like things are more cohesive. Should also move in the direction of having fewer knobs and dials for users to have to do to go with the Critter Stack in terms of how many Nugets have to be added or how many different settings need to be used
• Lamar just disappears, but will still be supported for usage within Wolverine. That work is close to done already
• We introduce a brand new, shared library called JasperFx.Framework that will hold some newer stuff related to shared configuration helpers and logic that is very specific to Marten/Wolverine/future critter stack tools, but not generic enough to live in JasperFx.Core that's just utilities and more or less the "junk drawer"
• Combine JasperFx.CodeGeneration into JasperFx.Framework
• LEAVE JasperFx.Compiler alone, other than to change its dependency to JasperFx.Framework
• Oakton goes away, with basically everything it does moving to the new shared JasperFx.Framework, including both the command line parsing and execution, as well as the IEnvironmentCheck and IStatefulResource models
• Fold the commands in Marten.CommandLine and really Weasel.CommandLine into Weasel.Core and/or Marten. Trying to get to fewer assemblies and less stuff to add
• Here's a hurtful one, move as much of the projection support in Marten including the async daemon code to a more generic JasperFx.Projections library. This is 100% in preparation for tackling "Ermine", the intended Sql Server backed event store lib

Finer Grained Thoughts

• Centralize the configuration of the code generation GenerationRules
• Centralize the application assembly determination that both Wolverine & Marten & Ermine in the future need
• Centralize the "optimize artifact workflow" logic that all the tools use
• Set us up for some streamlined bootstrapping alternatives. Anything that reduces the friction of starting a new project can only help