About the world choice of "aggregation" and "generation" on
https://gist.github.com/sgoeschl/b09b343a761b31a6c790d882167ff449. We
are "generating" files even if we are "aggregating". The project
itself is called freemarker-generator for that reason actually. (Also
"aggregation" is not really aggregating in the typical IT sense, I
think.) I think to present the concept in an easy to understand way,
we should express that you will have either one "transformation" per
template file (which you called "aggregation"), or one "tranformation"
per data-source (which you called "generation").

But the concept is even more important. Again, at very least because
of shared data (see mail before the previous), you will need to be
able to use both "aggreagation" and "generation" in the same
freemarker-cli run. Also there's the use case when you run one
"transformation" per row in a table. So, *for each* something you run
a "transformation", where that "something" can be a template, or a
data file, or an entry (a row) in a data file.

The tricky question is how to put all that in a sane way into CLI... I
will think about that. But we really shouldn't cripple the core
concept just because it's hard to express in a primitive interface
like CLI. Anyway, pretty certainly only the simplest use-cases will
look good on CLI, and for others, you will want to use a configuration
file, or Maven, or Gradle.

BTW, the "freemarker-cli" command should be really called
"freemarker-generator", which is the project name. The Maven task
isn't called "freemarker-maven" either. :) You are calling
freemarker-generator via CLI, or via Maven.

Also, you mentioned in last mail this idea of adding query parameters
to configure that data source. That I think will be difficult to do in
practice. Both the front-ends (CLI and Maven) has the concept of
collecting file paths for you. But they won't attach query parameters
to them for you. Also, data source configs can be long winded and
having nested structures, so you would often end up with ?setup=<some
JSON here>, which is quite horrible to URL encode and all.