Merging "freemarker-generator" & "freemarker-cli"

[Siegfried Goeschl <si...@gmail.com>]

Hi folks,

Unfortunately I'm busy with my day job but today I got my fingers dirty with "freemarker-generator" and holidays are near :-)

Some thoughts along the line

* Daniel suggested to move "freemarker-cli" into the "freemarker-generator" project

* Doing so I would set up a Maven multi-module project, e.g.  "freemarker-generator-base", "freemarker-generator-maven" & "freemarker-generator-cli"

* The "freemarker-generator-maven" project needs a bit of love, e.g. coding convention are different, no finals, ...

* "freemarker-generator-maven" will probably have little to no overlap with my code base or is there something useful missing?

* How to handle versioning & release cycles? Independent from Apache Freemarker or in sync having a "2.3.30". I would lean towards independent semantic versioning and release cycles ...

* How to handle JIRA issues? The current JIRA setup is geared towards FreeMarker only, e.g. there is no component "generator"

* Any other things I forgot and/or I'm not aware of?

Thanks in advance, 

Siegfried Goeschl

Re: Merging "freemarker-generator" & "freemarker-cli"

[Daniel Dekany <da...@gmail.com>]

>
> * Daniel suggested to move "freemarker-cli" into the
> "freemarker-generator" project
>

Yes. The main point is that being CLI is not a fundamental aspect, as
hopefully there will be a Maven plugin to call the same engine. That's
probably even a more frequent need that calling the same from CLI.
Similarly, calling it from Gradle plugin would be useful in the future.


> * Doing so I would set up a Maven multi-module project, e.g.
> "freemarker-generator-base", "freemarker-generator-maven" &
> "freemarker-generator-cli"
>

I agree, it should be multi-module.

* The "freemarker-generator-maven" project needs a bit of love, e.g. coding
> convention are different, no finals, ...
>

Probably there's no much to reuse there, because your project is more
mature, and the current freemarker-generator code packed too little
functionality too have a chance for forks and such.


> * "freemarker-generator-maven" will probably have little to no overlap
> with my code base or is there something useful missing?
>

Probably you are right there. Clearly, after the donation the code base had
no owner, so, as far as I'm concerned, you might as well go ahead and
replace it with yours. Except, did others contribute to that code, or can
your employee claim that it's their property (like you developed it during
work time, or on equipment provided by them)? Then we will have to do some
paper work first. Yeah, I assume you know these very well, but I think I
should ask anyway.


> * How to handle versioning & release cycles? Independent from Apache
> Freemarker or in sync having a "2.3.30". I would lean towards independent
> semantic versioning and release cycles ...
>

I think they should be versioned and released independently.


> * How to handle JIRA issues? The current JIRA setup is geared towards
> FreeMarker only, e.g. there is no component "generator"
>

Yes, we (like you) need to create a new Jira component, or category, or
whatever it's called in Jira.


> * Any other things I forgot and/or I'm not aware of?
>
> Thanks in advance,
>
> Siegfried Goeschl
>

On Fri, Jan 24, 2020 at 11:40 PM Siegfried Goeschl <
siegfried.goeschl@gmail.com> wrote:

> Hi folks,
>
> Unfortunately I'm busy with my day job but today I got my fingers dirty
> with "freemarker-generator" and holidays are near :-)
>
> Some thoughts along the line
>
> * Daniel suggested to move "freemarker-cli" into the
> "freemarker-generator" project
>
> * Doing so I would set up a Maven multi-module project, e.g.
> "freemarker-generator-base", "freemarker-generator-maven" &
> "freemarker-generator-cli"
>
> * The "freemarker-generator-maven" project needs a bit of love, e.g.
> coding convention are different, no finals, ...
>
> * "freemarker-generator-maven" will probably have little to no overlap
> with my code base or is there something useful missing?
>
> * How to handle versioning & release cycles? Independent from Apache
> Freemarker or in sync having a "2.3.30". I would lean towards independent
> semantic versioning and release cycles ...
>
> * How to handle JIRA issues? The current JIRA setup is geared towards
> FreeMarker only, e.g. there is no component "generator"
>
> * Any other things I forgot and/or I'm not aware of?
>
> Thanks in advance,
>
> Siegfried Goeschl
>
>

-- 
Best regards,
Daniel Dekany