Hi Daniel, Your observation is mostly correct (I did some changes along the way) - there is currently no overlap between the Maven plugin and the rest of the code base but this will change in the future.
Thanks in advance, Siegfried Goeschl > On 04.07.2020, at 10:20, Daniel Dekany <[email protected]> wrote: > > I took a better look at the Maven plugin, and realized that it's just the > plugin we inherited from the original donation, from before Siegfried's > donation. So no wonder it's so different (it doesn't even depend on > freemarker-generator-base). So what to do about this duality? The Maven > plugin is an example of "data-driver" from "template-driven VS data driven > output generation", which I brought up in last mail too. There's one output > file per JSON data file, and many JSON-s share the same template. So if the > freemarker-generator-base will support both approaches, we are one big step > closer to have a consistent product with two interfaces (CLI and Maven). > > On Sat, Jul 4, 2020 at 1:10 AM Daniel Dekany <[email protected]> > wrote: > >> It should be in https://freemarker.apache.org/generator/. You will need >> to commit/push into >> https://github.com/apache/freemarker-site/tree/asf-site for that. (See >> https://freemarker.apache.org/committer-howto.html#updating-homepage) >> >> We need to generate the web pages somehow though. I saw you try to do that >> with Maven "site", but personally, I can't imagine that it can be tweaked >> to generate reasonable output. Not sure how others see this. Maven "site" >> is basically the Maven model dumped into HTML pages, and "reports" like >> even the log of the Rat run etc. Dozens of menus and sub-pages for details >> users mostly don't care about. The actual content users do care about is >> stuffed under "About", and from there it's not properly navigable or >> searchable, as apparently it's assumed to be a single page. I know back >> then you didn't want to use the tool that's used both for the main web site >> and for the FreeMarker documentation, but I think that's the most >> economical solution currently (and then we also have common styling, and >> common place to fix whatever technical issues), so please reconsider that. >> (I can help setting that up, of course.) >> >> Now, some more difficult-to-address problematic things. My problem is that >> these just weren't concluded. Discussion just died. To be concluded can >> even mean that other PMC members say we should step over these, even if I >> disagree. But these should be understood, and considered. So, these are: >> >> - Design/architectural doubts that are probably not realistic to >> address much later: >> - Currently, data sources are just URL-s (locations), and templates >> are meant to call tool API-s to parse them. As I said back then, one >> consequence is that then, you can't put parsed data into the data-model >> shared by all templates (i.e., via -m/--data-model). Because, you have >> no >> convenient/concise way to load the actual (parsed) data, instead you >> have >> to "program it" in FTL, because the assumption was that you only want >> to do >> that in templates anyway. Furthermore, as I saw it just now, >> --data-model >> actually supports some ad-hoc way of parsing the data pointed by a >> data-source-like URL, as JSON, YAML, maybe some more. Here's an example >> of >> that: `-m config=env:///DB_CONFIG#mimetype=application/json`. So there >> is a >> need actually. But compared to what you can do in templeats, it's >> totally >> different, and of course very restrictive. I was also looking for a less >> "programmatic" way of loading data because even doing it in templates is >> not very friendly as it is. (For ultimate flexibility you might need >> program logic for sure, but certainly not just to grab a worksheet from >> an >> Excel file.) We also should have a POC for loading from a less file >> centric >> data source, like from a DB with a SQL query, to see if the concept >> works. >> - Not sure what's with template-driven VS data driven output >> generation. Data driven is when you generate one output file per some >> data >> unit (like per JSON file, or per DB record), and all is transformed by a >> common template. How would that look currently in freemarker-cli? >> - The Maven plugin provides very different functionality than the CLI. >> The original concept was that they are just two interfaces to the same >> product. That was also brought up, and I don't think it was addressed much, >> like, why you disagree, if you do, or what's going on. Anyway, regarding >> what we have now. The naming implies that, as both are "FreeMarker >> Generator", just one is "CLI", and the other is "Maven". But as far as I >> see, they are two different "products" really, focusing on different use >> cases. So, if it stays like this, then some of them have to be renamed at >> least. Or I don't know what others think we can do. (Then it's still >> somewhat weird to release them together.) >> >> (I have also run through the CLI documentation, and found a lot of less >> fundamental things to address, but I don't want to overload the thread.) >> >> Also, if the project is released mostly as it is now, what will we promise >> regarding backward compatibility? What do we communicate about the >> matureness of the project? >> >> On Wed, Jul 1, 2020 at 8:29 AM Siegfried Goeschl < >> [email protected]> wrote: >> >>> Hi folks, >>> >>> I'm pretty much finished with the stuff I would like to have for the >>> first public release but there is a still a lot of work ahead >>> >>> * FREEMARKER-148 [freemarker-cli] Make usage of "DataSources" more >>> "Freemarker" like >>> * FREEMARKER-150 [freemarker-cli] Setup "freemarker-generator" web site >>> * Setup the release process (Daniel, I guess I need some help here) >>> * An iteration of reviews and discussions >>> >>> Some thought along the line >>> >>> * I would like to finish FREEMARKER-148 this week >>> * Daniel, any suggestion where to host the public website? >>> >>> Thanks in advance, >>> >>> Siegfried Goeschl >>> >>> >> >> -- >> Best regards, >> Daniel Dekany >> > > > -- > Best regards, > Daniel Dekany
