Re: Moving JBoss FreeMarker IDE (Eclipse plugin) to the ASF?

[Taher Alkhateeb]

Great idea. Love to help if I can

On Mar 7, 2018 7:08 PM, "Daniel Dekany"  wrote:

> The only Eclipse plugin in reasonable state for editing FreeMarker
> templates is "FreeMarker IDE", which is part of the JBoss Tools
> project. See the top entry at
> https://freemarker.apache.org/editors.html, and also
> https://github.com/jbosstools/jbosstools-freemarker.
>
> However, RedHat has deprecated and now removed the "FreeMarker IDE"
> plugin from JBoss Tools and Devstudio. See:
> https://stackoverflow.com/questions/49072160/why-is-
> freemarker-ide-in-eclipse-oxygen-jboss-tools-4-5-2-final-deprecated
> https://issues.jboss.org/browse/JBIDE-25736
>
> So I think "FreeMarker IDE" should be brought over to the ASF,
> similarly as FreeMarker-Online was. Also the Eclipse update "site"
> should be hosted on ASF infrastructure. I have started a discussion to
> explore this possibility, and so far it seems it's fine on their side:
>
> http://lists.jboss.org/pipermail/jbosstools-dev/2018-March/subject.html
>
> The code is under EPL, but of course they should "contribute" the code
> the ASF where we can replace the license with ASL2, and rename the
> packages.
>
> Technically, "FreeMarker IDE" is independent of the rest of JBoss
> Tools, we only had to substitute org.jboss.tools:parent (as it's not
> in the Maven Central, it's not an acceptable dependency IMO).
>
> What do you think? Will the ASF be fine with bringing over yet another
> FreeMarker related project? Do you think it's good to do?
>
> My opinion is that the more control we have over such products, the
> easier it is to ensure that they remain maintained and available to
> the users.
>
> --
> Thanks,
>  Daniel Dekany
>
>

Re: Proposal for FREEMARKER-84: More flexible handlig of missing templates

[Taher Alkhateeb]

I feel clumsy now :) Thank you for the explanation, I'm beginning to
understand this a bit. I'll follow up on the JIRA

On Sat, Feb 17, 2018 at 7:57 PM, Daniel Dekany <ddek...@apache.org> wrote:
> Saturday, February 17, 2018, 2:36:37 PM, Taher Alkhateeb wrote:
>
>> Ahh I see, I guess that's the layer of complexity Jacopo was pointing
>> to (fall back mechanism). Every time I engage here I learn something
>> :) In this case I stand neutral. it sounds a bit challenging but I
>> have zero knowledge of the code base and perhaps the architecture
>> allows for that.
>
> It allows that. It's already possible to do with the public
> Environment Java API. It's just that then you had to implement a
> custom TemplateDirectiveModel and all... and it might not be so easy
> to do (or to do correctly) for an average user.
>
> Anyway, an important selling point of FreeMarker is that you generally
> have to run less circles to make developers add this-and-that tool,
> also to find the typically lacking documentation of in-house
> directives, because lot of the stuff is there out-of-the-box and is
> documented in the Manual. (Except that people enjoy using ancient
> FreeMarker versions... like 2.3.19(!) and 2.3.23 are big favorites.)
>
>> I find this over all intriguing and interesting, if you intend to work
>> on this feature would you mind sharing the JIRA number so I can follow
>> on the code changes?
>
> It's in the thread Subject... :)
> https://issues.apache.org/jira/browse/FREEMARKER-84
>
>
>> On Sat, Feb 17, 2018 at 4:06 PM, Daniel Dekany <ddek...@apache.org> wrote:
>>> Saturday, February 17, 2018, 9:36:48 AM, Taher Alkhateeb wrote:
>>>
>>>> Wrong link, sorry, correcting.
>>>>
>>>> http://jinja.pocoo.org/docs/2.10/templates/#include
>>>
>>> Just be sure it's clear, we also have an ignore_missing option (in the
>>> released versions). But it's often not very useful if you can't do
>>> some action in case the template is missing.
>>>
>>> Jinja also allows you to specify a list of template names instead of
>>> just one, and uses that as a fallback list. That's something I have
>>> considered as well, and I believe it covers most use-cases for the
>>> proposed feature. However, it falls into the same mistake as
>>> ingnore_missing, as it focuses on a concrete use-case while missing
>>> another (when you have to do something before the template if it
>>> exists). I prefer less but more generic devices. With that could have
>>> avoid adding ignore_missing as well.
>>>
>>>> On Feb 17, 2018 11:34 AM, "Taher Alkhateeb" <slidingfilame...@gmail.com>
>>>> wrote:
>>>>
>>>>> For a point of comparison, the python jinja2 template engine (widely used)
>>>>> has an "include" directive that has an attribute named "ignore missing"
>>>>> [1]. I also remember seeing similar behavior in other engines.
>>>>>
>>>>> So I guess perhaps from a usability point of view this seems to be a
>>>>> desired feature by users. However, I don't know what the impact in terms 
>>>>> of
>>>>> complexity would reflect in the code base.
>>>>>
>>>>> http://jinja.pocoo.org/docs/2.10/templates/#list-of-global-functions
>>>>>
>>>>> On Feb 17, 2018 11:18 AM, "Jacopo Cappellato" 
>>>>> <jacopo.cappell...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Fri, Feb 16, 2018 at 8:04 AM, Daniel Dekany <ddek...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>> > Some more opinions guys? Especially as we got one opinion against the
>>>>>> > feature.
>>>>>> >
>>>>>>
>>>>>> Just to clarify my opinion: I am not against this feature; I simply don't
>>>>>> consider it a must since there are some workaround to get a similar
>>>>>> behavior. But if it will be implemented I will be happy too.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>
>>>
>>> --
>>> Thanks,
>>>  Daniel Dekany
>>>
>>
>
> --
> Thanks,
>  Daniel Dekany
>

Re: Proposal for FREEMARKER-84: More flexible handlig of missing templates

[Taher Alkhateeb]

Wrong link, sorry, correcting.

http://jinja.pocoo.org/docs/2.10/templates/#include

On Feb 17, 2018 11:34 AM, "Taher Alkhateeb" <slidingfilame...@gmail.com>
wrote:

> For a point of comparison, the python jinja2 template engine (widely used)
> has an "include" directive that has an attribute named "ignore missing"
> [1]. I also remember seeing similar behavior in other engines.
>
> So I guess perhaps from a usability point of view this seems to be a
> desired feature by users. However, I don't know what the impact in terms of
> complexity would reflect in the code base.
>
> http://jinja.pocoo.org/docs/2.10/templates/#list-of-global-functions
>
> On Feb 17, 2018 11:18 AM, "Jacopo Cappellato" <jacopo.cappell...@gmail.com>
> wrote:
>
>> On Fri, Feb 16, 2018 at 8:04 AM, Daniel Dekany <ddek...@apache.org>
>> wrote:
>>
>> > Some more opinions guys? Especially as we got one opinion against the
>> > feature.
>> >
>>
>> Just to clarify my opinion: I am not against this feature; I simply don't
>> consider it a must since there are some workaround to get a similar
>> behavior. But if it will be implemented I will be happy too.
>>
>> Jacopo
>>
>

Re: Proposal for FREEMARKER-84: More flexible handlig of missing templates

[Taher Alkhateeb]

For a point of comparison, the python jinja2 template engine (widely used)
has an "include" directive that has an attribute named "ignore missing"
[1]. I also remember seeing similar behavior in other engines.

So I guess perhaps from a usability point of view this seems to be a
desired feature by users. However, I don't know what the impact in terms of
complexity would reflect in the code base.

http://jinja.pocoo.org/docs/2.10/templates/#list-of-global-functions

On Feb 17, 2018 11:18 AM, "Jacopo Cappellato" 
wrote:

> On Fri, Feb 16, 2018 at 8:04 AM, Daniel Dekany  wrote:
>
> > Some more opinions guys? Especially as we got one opinion against the
> > feature.
> >
>
> Just to clarify my opinion: I am not against this feature; I simply don't
> consider it a must since there are some workaround to get a similar
> behavior. But if it will be implemented I will be happy too.
>
> Jacopo
>

Re: Resolution draft for graduation, members

[Taher Alkhateeb]

I'm not highly involved in this project but I thought I'd make a comment
from my brief experience. Daniel to me seems to be a heavy duty lifter. I
was surprised at how fast he got features and code committed. In addition I
think he has a clear vision for the project and its roadmap. He is open to
ideas and cares about the project and wants to build a community. To me
this makes him a good candidate.

I am not the most active here so I apologize if my comments are out of
place. Just my 2 cents.

Cheers,

Taher Alkhateeb

On Jan 8, 2018 12:06 PM, "Daniel Dekany" <ddek...@apache.org> wrote:

Monday, January 8, 2018, 6:30:33 AM, Ralph Goers wrote:

> You would probably be better served by having someone else
> volunteer to be PMC chair. My reasoning for that is exactly for the
> same reason you put yourself there. You are the most active
> committer and obviously aren’t going anywhere. Having someone else
> be chair insures that someone else is staying fairly involved in the
> activities of the project, even if they aren’t the most active
> committer. You need at least 3 active PMC members so use any
> opportunity you can to make sure you stay above that mark.

Since it's a voluntarily position, let's see who wants that
responsibility. Guys, anyone wants to be a PMC chair if the project
graduates?

> Ralph
>
>> On Jan 7, 2018, at 1:08 PM, David E Jones <d...@dejc.com> wrote:
>>
>> Looks good Daniel, may it be resolved!
>>
>> -David
>>
>> On Fri, Jan 5, 2018 at 1:08 PM, Daniel Dekany <ddek...@apache.org> wrote:
>>
>>> Here's the Resolution you will vote on (at least that's my plan) in
>>> the graduation VOTE here on the poddling list. Anyone sees any
>>> oversight in it?
>>>
>>> As of the list of project members, I have listed everyone who said
>>> that he/she intends to stay so far. Anyone else? In the current list,
>>> everyone intends to be in the PMC as well.
>>>
>>> About the "be appointed to the office of Vice President" thing. Who
>>> should be it? I have written there myself for now, as I'm by far the
>>> most involved with the project. But maybe someone else fits that role
>>> better. I don't fancy titles, no offense taken in that case.
>>>
>>> And, as always... if you can, please check if we miss any formal
>>> requirements for graduation!
>>>
>>> 
>>>
>>> Establish the Apache FreeMarker Project
>>>
>>> WHEREAS, the Board of Directors deems it to be in the best
>>> interests of the Foundation and consistent with the
>>> Foundation's purpose to establish a Project Management
>>> Committee charged with the creation and maintenance of
>>> open-source software, for distribution at no charge to
>>> the public, related to a template engine.
>>>
>>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>>> Committee (PMC), to be known as the "Apache FreeMarker Project",
>>> be and hereby is established pursuant to Bylaws of the
>>> Foundation; and be it further
>>>
>>> RESOLVED, that the Apache FreeMarker Project be and hereby is
>>> responsible for the creation and maintenance of software
>>> related to a template engine, and be it further
>>>
>>> RESOLVED, that the office of "Vice President, Apache FreeMarker" be
>>> and hereby is created, the person holding such office to
>>> serve at the direction of the Board of Directors as the chair
>>> of the Apache FreeMarker Project, and to have primary responsibility
>>> for management of the projects within the scope of
>>> responsibility of the Apache FreeMarker Project; and be it further
>>>
>>> RESOLVED, that the persons listed immediately below be and
>>> hereby are appointed to serve as the initial members of the
>>> Apache FreeMarker Project:
>>>
>>>  * Dániel Dékány   <ddek...@apache.org>
>>>  * David E. Jones  <jone...@apache.org>
>>>  * Jacopo Cappellato   <jaco...@apache.org>
>>>  * Jacques Le Roux <jler...@apache.org>
>>>  * Sergio Fernández<wik...@apache.org>
>>>  * Woonsan Ko  <woon...@apache.org>
>>>
>>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Dániel Dékány
>>> be appointed to the office of Vice President, Apache FreeMarker,
>>> to serve in accordance with and subject to the direction of the
>>> Board of Directors and the Bylaws of the Foundation until
>>> death, resignation, retirement, removal or disqualification,
>>> or until a successor is appointed; and be it further
>>>
>>> RESOLVED, that the Apache FreeMarker Project be and hereby
>>> is tasked with the migration and rationalization of the Apache
>>> Incubator FreeMarker podling; and be it further
>>>
>>> RESOLVED, that all responsibilities pertaining to the Apache
>>> Incubator FreeMarker podling encumbered upon the Apache Incubator
>>> Project are hereafter discharged.
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>>>
>
>
>

--
Thanks,
 Daniel Dekany

Re: Alternative to ${exp}

[Taher Alkhateeb]

Sounds good.

On Dec 15, 2017 1:28 PM, "Daniel Dekany" <ddek...@apache.org> wrote:

> OK, so I would go for [=exp] (see the reason told in this thread). How
> acceptable is that guys?
>
>
> Tuesday, December 5, 2017, 11:56:59 AM, Woonsan Ko wrote:
>
> > On Mon, Dec 4, 2017 at 10:28 AM, Daniel Dekany <ddek...@apache.org>
> wrote:
> >> Monday, December 4, 2017, 10:21:48 AM, Taher Alkhateeb wrote:
> >>
> >>> uh-huh, but I suspect maybe more collisions or need to escape
> >>> character in something like [this] or  than {{this}}. Anyway,
> >>> nothing critical IMO, only thinking out loud.
> >>
> >> But they were [=this] and <=this>, so the sequences that will clash
> >> are "[=" and "<=", which are quite rare. Oh wait... "<=" is not rare
> >> at all: "if (x <= y)". But "[=" still is. OK, so I guess at this point
> >> the two competitors left are {{exp}} and [=exp] (regardless of tag
> >> syntax).
> >
> > +1.00 on [=exp].
> > +0.49 on {{exp}}.
> >
> > :-D
> >
> > Many languages or templates allows ${exp}, including JavaScript. [1]
> > And, mustache is supported in many languages or templates, too. [2]
> > Therefore, I think there are more chances using both ${exp} and
> > {{exp}} in output we want to generate in the future.
> > The mustache style looks charming at the moment, but I wonder how its
> > charming can help for the original intention (to avoid any possible
> > collision in the output we want to generate by an alternative as much
> > as we can).
> >
> > Regards,
> >
> > Woonsan
> >
> > [1] https://en.wikipedia.org/wiki/String_interpolation
> > [2] https://mustache.github.io/
> >
> >>
> >>> On Mon, Dec 4, 2017 at 12:00 PM, Daniel Dekany <ddek...@apache.org>
> wrote:
> >>>> Monday, December 4, 2017, 9:17:34 AM, Taher Alkhateeb wrote:
> >>>>
> >>>>> So maybe a safe bet (and a familiar one) is the mustache syntax.
> >>>>>
> >>>>> In addition to avoiding clashes it might help with a multi-chained
> >>>>> template. For example, we use FreeMarker extensively in Apache OFBiz
> >>>>> to generate many documents including XML. Now our XML documents might
> >>>>> contain some ${variable} that needs to be interpreted in the XML
> >>>>> parser, not the freemarker parser (without having to escape
> characters
> >>>>> everywhere)
> >>>>
> >>>> Though that also works with all the other proposal syntaxes as well.
> >>>>
> >>>>> On Mon, Dec 4, 2017 at 8:50 AM, Jacques Le Roux
> >>>>> <jacques.le.r...@les7arts.com> wrote:
> >>>>>> Le 03/12/2017 à 22:06, Woonsan Ko a écrit :
> >>>>>>>
> >>>>>>> It is also most productive as no shift key is required.
> >>>>>>
> >>>>>> Depends on keyboard, for French keyboard type (azerty) you need to
> use Alt
> >>>>>> key ;)
> >>>>>> Same for {{...}} anyway
> >>>>>>
> >>>>>> Jacques
> >>>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Thanks,
> >>>>  Daniel Dekany
> >>>>
> >>>
> >>
> >> --
> >> Thanks,
> >>  Daniel Dekany
> >>
> >
>
> --
> Thanks,
>  Daniel Dekany
>
>

Re: Alternative to ${exp}

[Taher Alkhateeb]

So maybe a safe bet (and a familiar one) is the mustache syntax.

In addition to avoiding clashes it might help with a multi-chained
template. For example, we use FreeMarker extensively in Apache OFBiz
to generate many documents including XML. Now our XML documents might
contain some ${variable} that needs to be interpreted in the XML
parser, not the freemarker parser (without having to escape characters
everywhere)

On Mon, Dec 4, 2017 at 8:50 AM, Jacques Le Roux
 wrote:
> Le 03/12/2017 à 22:06, Woonsan Ko a écrit :
>>
>> It is also most productive as no shift key is required.
>
> Depends on keyboard, for French keyboard type (azerty) you need to use Alt
> key ;)
> Same for {{...}} anyway
>
> Jacques
>

Re: FreeMarker 3 wiki page - please review it

[Taher Alkhateeb]

Very cool. This document explains the purpose of FM3 and puts things into
perspective. I learned something new so thank you for sharing.

The only thing that I can suggest is to group together the intended
backwards breaking changes under a header to distinguish it from
improvements.

On Jun 12, 2017 2:34 PM, "Daniel Dekany"  wrote:

> I have made a page about what FreeMarker 3 is about and how it should
> look, because all this was only extractable from mailing list
> discussions so far.
>
> https://cwiki.apache.org/confluence/display/FREEMARKER/FreeMarker+3
>
> Something you are missing from it, or disagree with it? Eventually we
> should tweet this, but first of course I need some feedback.
>
> --
> Thanks,
>  Daniel Dekany
>
>

Re: [FM3] Migration to Gradle

[Taher Alkhateeb]

Yeah I closed it because it was a proposal for a PoC which you pretty much
got done while I slacked :) Should I re-open? If yes then perhaps it should
be renamed by removing the "PoC" part?



On Tue, May 16, 2017 at 11:10 PM, Daniel Dekany  wrote:

> I saw the Jira issue for migrating to Gradle was closed, but to be
> clear it's far from done. Like, a major TODO is building the release
> artifacts; the root project should do that (or should that be yet
> another sub-project instead?).
>
> The second most important deficiency is producing all the 3 Maven
> artifacts for each published module (the usual artifact plus src and
> javadoc). Currently we only produce one artifact per module, and it's
> not even signed.
>
> BTW, I have factored out Manual generation into freemarker-manual
> (non-published module). There's also a TODO there as its build doesn't
> produce anything yet.
>
> --
> Thanks,
>  Daniel Dekany
>
>

Re: [FM3] Migration to Gradle

[Taher Alkhateeb]

Hi Daniel,

Inline ...

On Mon, May 15, 2017 at 12:17 PM, Daniel Dekany <ddek...@apache.org> wrote:

> Monday, May 15, 2017, 8:27:07 AM, Taher Alkhateeb wrote:
>
> > Hi Daniel,
> >
> > Great work! a few issues:
> > - the gradlew wrapper script mode needs to switch to be executable (unix
> > flag)
> > - gradle is running a lot of stuff in the configuration phase, before we
> > even know what it does. For example, running ./gradlew tasks gives me the
> > below error. This means that not only is it expecting a flag, but also
> > executing considerable work in the configuration phase. I prefer to
> always
> > delay work until I need it, which is usually in the execution phase.
>
> My understanding is that in Gradle you are supposed to do the
> configuration tasks up front. If they take considerable time, that's a
> problem and may warrant deviating from that, but in our case I doubt
> they take any perceivable time.
>

First forgive me for my ignorance as I did not check all the details of
what's happening exactly in the script, and I guess there are no rights and
wrongs, just a preference issue. What I suggested is to prepare things when
needed is because sometimes not all tasks require the same preparation, and
so running the preparation every time you run gradlew might consume some
resources, if not then ignore my comment :)


>
> As of the error message, do you mean that we should do those checks in
> [compileJava, compileTestJava]*.doFirst, so that you can run other
> tasks that do not need those properties without setting up things as
> the README.md dictates? Then I think we gain little with that as in
> practice one can't do any real work without compiling something
> anyway, and on the same time it makes the script harder to
> understand/maintain, because that's not the standard away of doing
> things (moving configuration activity part the configuration phase).
> Also note that in the root we provide the defaults, and in some other
> subprojects we override them, which works now as it used to be done in
> Gradle, but with doFirst it will become trickier.
>

Again I think no rights and wrongs here, just preferences and consequences.
For example, in ant you can type "ant -p" to list tasks. The equivalent of
that in gradle is "gradlew tasks". However, this task will simply fail
because it cannot proceed past the configuration phase, so people who want
to know what tasks are available and how to use them might be a bit
confused. The same is true if you want to view projects "./gradlew
projects" or other such informational tasks.


>
> > - I tried to tackle the first TODO that pulls configuration from your
> > properties file (a small patch, so I put it in this email). Is this what
> > you're looking for?
> >
> >  Patch for properties loading 
> > diff --git a/build.gradle b/build.gradle
> > index d47fa9e..5f4e8cb 100644
> > --- a/build.gradle
> > +++ b/build.gradle
> > @@ -17,11 +17,12 @@
> >   * under the License.
> >   */
> >
> > -// TODO: Versions should come form
> > src/main/resource/o/a/f/c/version.properties
> > -ext.versionCanonical = "3.0.0-nightly-incubating"
> > -ext.versionForMaven = "3.0.0-SNAPSHOT"
> > -ext.versionForOSGi = "3.0.0.nightly-incubating"
> > -ext.versionForMf = "2.97.0"
> > +Properties props = new Properties()
> > +props.load(file('freemarker-core/src/main/resources/org/
> apache/freemarker/core/version.properties').newDataInputStream())
> > +ext.versioncanonical = props.getProperty('version')
> > +ext.versionformaven = props.getProperty('mavenVersion')
> > +ext.versionforosgi = props.getProperty('versionForOSGi')
> > +ext.versionformf = props.getProperty('versionForMf')
>
> Yes, something like that. But I haven't looked after how Gradle will
> know if those variables depend on that file (or if have to care about
> that at all), what will happen if a property is missing, all the
> details like that...
>

Well, I guess the simplest solution if you want to assign-if-null is simply
by changing the above code as follows:
ext.versioncanonical = props.getProperty('version', 'MyDefaultValueHere')

Please tell me if I can / should help with any of that?

HTH


>
> >  allprojects {
> >  group = "org.apache.freemarker"
> >  end of patch 
> >
> >  error message when running ./gradlew tasks 
> >   % Total% Received % Xferd  Average Speed   TimeTime Time
> > Current
> >  Dload  Upload   Total   SpentLeft
> > Speed
> >   0 00 00 0  0  0 --:--:--

Re: include with custom parameter

[Taher Alkhateeb]

Oops .. terribly sorry, I actually thought I was on the OFBiz mailing list
:) My bad

On Mon, Apr 3, 2017 at 11:46 AM, Taher Alkhateeb <slidingfilame...@gmail.com
> wrote:

> Oops, crossed on wire. Thank you for pitching in, I guess the thread is
> answered now :)
>
> On Mon, Apr 3, 2017 at 11:43 AM, Daniel Dekany <ddek...@apache.org> wrote:
>
>> Hello,
>>
>> There's no such feature. If a reusable template fragment has
>> parameters (or has nested content), then you meant to use macros (or
>> functions).
>>
>>
>> Sunday, April 2, 2017, 11:47:54 PM, Ingo Mahnke wrote:
>>
>> > Hallo,
>> > maybe someone can help me.
>> > Is it possibile to use custom parameter with the include directive?
>> >
>> >
>> > Template 1
>> > 
>> > 
>> > <#include "template2.ftl" param=v1>
>> > ...
>> > ..
>> >
>> >
>> > template2.ftl
>> > 
>> > ...
>> > <#if (param=="v1")>
>> > ..
>> > ..
>> > <#else>
>> > ..
>> > ..
>> > 
>> >
>> >
>> > Thank you very much!!!
>> >
>> > Ingo
>> >
>> >
>>
>> --
>> Thanks,
>>  Daniel Dekany
>>
>>
>

Re: include with custom parameter

[Taher Alkhateeb]

Oops, crossed on wire. Thank you for pitching in, I guess the thread is
answered now :)

On Mon, Apr 3, 2017 at 11:43 AM, Daniel Dekany  wrote:

> Hello,
>
> There's no such feature. If a reusable template fragment has
> parameters (or has nested content), then you meant to use macros (or
> functions).
>
>
> Sunday, April 2, 2017, 11:47:54 PM, Ingo Mahnke wrote:
>
> > Hallo,
> > maybe someone can help me.
> > Is it possibile to use custom parameter with the include directive?
> >
> >
> > Template 1
> > 
> > 
> > <#include "template2.ftl" param=v1>
> > ...
> > ..
> >
> >
> > template2.ftl
> > 
> > ...
> > <#if (param=="v1")>
> > ..
> > ..
> > <#else>
> > ..
> > ..
> > 
> >
> >
> > Thank you very much!!!
> >
> > Ingo
> >
> >
>
> --
> Thanks,
>  Daniel Dekany
>
>

Re: Re: Re: include with custom parameter

[Taher Alkhateeb]

Okay so just to clarify things, we have 3 mailing lists under discussion:
- Apache OFBiz developer mailing list strictly for topics related to the
design and development of the OFBiz Project itself
- Apache OFBiz user mailing list for installation, deployment, custom
development and usage related topics
- Apache FreeMarker mailing list: They only have one list which you
mentioned.

So my recommendation to you was to redirect your question from dev@ofbiz to
user@ofbiz because your question is more relevant over there. I think you
misunderstood my suggestion and thought I meant the FreeMarker ML.

So there are two possible places to ask your question, the user mailing
list for OFBiz, or directly in the FreeMarker mailing list. I think it
makes more sense to ask in the user list of OFBiz because you need
FreeMarker in the context of OFBiz but it's up to you.

So there you, I hope this explains things!

On Mon, Apr 3, 2017 at 11:12 AM, Ingo Mahnke <ingo.mah...@quvion.org> wrote:

> Hallo Taher,
> why I should subscribe to the OfBiz userlist?
>
>
> On "lists.apache.org" I found only the "d...@freemarker.apache.org" list.
>
> Ingo
>
>
>
> > Gesendet: Montag, 03. April 2017 um 10:04 Uhr
> > Von: "Taher Alkhateeb" <slidingfilame...@gmail.com>
> > An: dev@freemarker.incubator.apache.org
> > Betreff: Re: Aw: Re: include with custom parameter
> >
> > Oh I meant the OFBiz user mailing list. Anyway FreeMarker is an Apache
> > project now so the mailing list changed. You need to follow the new one
> > provided in lists.apache.org
> >
> > On Apr 3, 2017 10:34 AM, "Ingo Mahnke" <ingo.mah...@quvion.org> wrote:
> >
> > > Hi Thaer,
> > > good idea.
> > >
> > > I tried to subscribe on "http://freemarker.org/mailing-lists.html; and
> > > clickd on "freemarker-u...@lists.sourceforge.net" -> 404
> > >
> > > Any other method to subscribe?
> > >
> > > Ingo
> > >
> > >
> > >
> > >
> > >
> > > > Gesendet: Montag, 03. April 2017 um 09:20 Uhr
> > > > Von: "Taher Alkhateeb" <slidingfilame...@gmail.com>
> > > > An: dev@freemarker.incubator.apache.org
> > > > Betreff: Re: include with custom parameter
> > > >
> > > > Hi Ingo,
> > > >
> > > > I think this question fits more in the user mailing list.
> > > >
> > > > Regards,
> > > >
> > > > On Mon, Apr 3, 2017 at 12:47 AM, Ingo Mahnke <ingo.mah...@quvion.org
> >
> > > wrote:
> > > >
> > > > > Hallo,
> > > > > maybe someone can help me.
> > > > > Is it possibile to use custom parameter with the include directive?
> > > > >
> > > > >
> > > > > Template 1
> > > > > 
> > > > > 
> > > > > <#include "template2.ftl" param=v1>
> > > > > ...
> > > > > ..
> > > > >
> > > > >
> > > > > template2.ftl
> > > > > 
> > > > > ...
> > > > > <#if (param=="v1")>
> > > > > ..
> > > > > ..
> > > > > <#else>
> > > > > ..
> > > > > ..
> > > > > 
> > > > >
> > > > >
> > > > > Thank you very much!!!
> > > > >
> > > > > Ingo
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: include with custom parameter

[Taher Alkhateeb]

Hi Ingo,

I think this question fits more in the user mailing list.

Regards,

On Mon, Apr 3, 2017 at 12:47 AM, Ingo Mahnke  wrote:

> Hallo,
> maybe someone can help me.
> Is it possibile to use custom parameter with the include directive?
>
>
> Template 1
> 
> 
> <#include "template2.ftl" param=v1>
> ...
> ..
>
>
> template2.ftl
> 
> ...
> <#if (param=="v1")>
> ..
> ..
> <#else>
> ..
> ..
> 
>
>
> Thank you very much!!!
>
> Ingo
>
>

Re: Gradle for FreeMarker, anyone? (Was: Maven for Freemarker)

[Taher Alkhateeb]

Hello Folks,

Okay I've been trying to migrate the compile task to gradle, but did not
expect so many hacks and quirks in this target. I can copy instructions
blindly but then that wouldn't make much sense since gradle operates very
differently with its declarative approach. Examples of where it was
confusing:

- boot classpath checks? Why do they exist
- regex replacements of Java source files! What's the story behind that
- why is the rmic compiler used?
- why do we have many separate ivy:cachepath declarations? do we have
different artifacts?
- Why are we manually copying files?

I think if we can have some interactive session or something to get my head
around the logic of this build then this would help me in translating it.
My conclusion so far is that either the product is inherently complex, or
the build logic is painfully manual. Getting the big picture of what is
happening is lost in the midst of these unending build instructions.

I also am under the impression that the code base should be a multi-project
architecture given this constant shoving of files around. Am I correct in
my conclusions so far?

On Tue, Feb 14, 2017 at 11:00 PM, Daniel Dekany <ddek...@freemail.hu> wrote:

> Tuesday, February 14, 2017, 7:53:36 PM, Mauricio Nuñez wrote:
>
> > Hi,
> >
> > I have a question about this. With FM2, the ant script allows differents
> > combinations. I think this is not needed for FM3. Or we need to be aware
> > about specifics combinations of dependencies? This is related to drop
> > support to older dependencies in FM3.
>
> We certainly will need to be able to support multiple versions of the
> same library in FM3 too, though such cases will be much fewer at the
> beginning. However, it's possible that in FM3 we solve that with
> modularization (where each module is a separate jar and a separate
> Maven artifact, and so can be built separately). It was already
> decided that we will modularize FM3 to freemarker-core,
> freemarker-sevlet, etc. So that's modularization by functionality.
> Perhaps we should modularize further by dependency version. For
> example, we could have freemarker-core-java8, which adds java.time
> support to freemarker-core. So then, freemarker-core can remain purely
> Java 7 (the minimal required version of FM3), and
> freemarker-core-java-8 contains all that depends on Java 8, and
> freemarker-core finds freemarker-core-java-8 via the SPI mechanism of
> the Java platform (if that works reliably in all environments...).
> But, while that's the cleanest solution as far as the build goes, it's
> not necessary the most convenient solution for the user. He now has to
> remember adding a dependency on freemarker-core-java-8 manually (if he
> wants time API support). Things can get worse if this happens with
> some other modules as well, like we have freemarker-serlet, and later
> we realize that we will need a freemarker-servlet-5 as well. We can
> hope that such things won't happen in reality, but the history of FM2
> shows otherwise. (And the absolute horror is if you have to support
> permutations of the versions of multiple dependencies for the same
> functional module... but let's assume we won't be so unlucky.) Compare
> this to FM2, where the user didn't have to care... you drop in
> freemarker.jar, and it discovers its environment automatically.
>
> I wonder if we could modularize FM2 on the source code level too, but
> then smash all the output together into a single jar (and that's the
> published artifact), while in FM3 they would remain separately
> published artifacts. Thus the FM2 and FM3 would be more similar.
>
> > Regards,
> >
> > Mauricio
> >
> >
> >
> > 2017-02-14 15:39 GMT-03:00 Taher Alkhateeb <slidingfilame...@gmail.com>:
> >
> >> Yeah that would be my bad :) We've been doing heart surgery in the OFBiz
> >> project that got me delayed a bit.
> >>
> >> Anyway, to share what I've worked on so far, I realized most of the
> >> complexity in the script is in the "compile" target. There is _lots_ of
> >> shuffling files around and a good amount of ivy:cachepath directives. I
> did
> >> not expect the logic to be so customized.
> >>
> >> I would like to add a build.gradle file that for now only handles this
> >> target, I will try to deliver something soon but this work should
> really go
> >> in baby steps ... it was overwhelming to try to do it all in one shot.
> >> Perhaps I can put a skeleton and we can work together to improve it.
> >>
> >> Anyway, sit tight, I'll work on something in the next few days.
> >>
> >> On Tue, Feb 14, 2017 at 5:23 PM, Daniel Dekany <ddek...@freemail.hu>
> >&

Re: Gradle for FreeMarker, anyone? (Was: Maven for Freemarker)

[Taher Alkhateeb]

Yeah that would be my bad :) We've been doing heart surgery in the OFBiz
project that got me delayed a bit.

Anyway, to share what I've worked on so far, I realized most of the
complexity in the script is in the "compile" target. There is _lots_ of
shuffling files around and a good amount of ivy:cachepath directives. I did
not expect the logic to be so customized.

I would like to add a build.gradle file that for now only handles this
target, I will try to deliver something soon but this work should really go
in baby steps ... it was overwhelming to try to do it all in one shot.
Perhaps I can put a skeleton and we can work together to improve it.

Anyway, sit tight, I'll work on something in the next few days.

On Tue, Feb 14, 2017 at 5:23 PM, Daniel Dekany <ddek...@freemail.hu> wrote:

> Any update regarding the Gadle-isation?
>
>
> Monday, January 2, 2017, 9:36:03 AM, Taher Alkhateeb wrote:
>
> > Hi Daniel,
> >
> > Okay things are much more clear thank you!
> >
> > With respect to the repository, I guess there are two uses of the word
> > repository. On one hand it is what you meant (a place to publish your
> > artifacts) and on another hand it is where you pull your dependencies
> from
> > (libraries).
> >
> > What I mean is the second form (pulling dependencies). Do you want to
> pull
> > from MavenCentral, or do you prefer to pull from JCenter? To give you
> some
> > perspective on the difference this might be helpful ->
> > http://stackoverflow.com/questions/24852219/android-
> buildscript-repositories-jcenter-vs-mavencentral#28457914
> >
> > Cheers,
> >
> > Taher Alkhateeb
> >
> > On Mon, Jan 2, 2017 at 11:29 AM, Daniel Dekany <ddek...@freemail.hu>
> wrote:
> >
> >> Monday, January 2, 2017, 8:14:25 AM, Taher Alkhateeb wrote:
> >>
> >> > Hi Daniel,
> >> >
> >> > Okay thank you for all the feedback. I will start to experiment in
> code a
> >> > little bit, but a few more lingering comments / questions:
> >> >
> >> > # Comments
> >> > - Every project optionally ends with a jar, but again, you can tweak
> that
> >> > to your liking.
> >> > - Embedded Ant is pretty clean code (we use it a lot). Ant is a first
> >> class
> >> > citizen in Gradle and fully integrated syntax wise (it's not XML)
> >> > - Your comment on JavaCC is similar to multi-project architecture
> >> > - Gradle has built-in plugins for both Eclipse and Intellij with quite
> >> > powerful DSL for customization
> >> >
> >> > # Questions
> >> > - The code directory structure is strange to me. By convention src
> means
> >> a
> >> > directory for all source code in multiple different languages. So it
> >> could
> >> > be something like src/main/java src/test/java src/main/groovy etc ...
> >>
> >> I have a "javacc" directory on that level, which is a language so it
> >> fits into this, and "misc" which are the things I don't know here else
> >> to put, but they still belong to the sources of "main"...
> >>
> >> > However, you have other directories that sound to me like "resources"
> or
> >> > such rather than src like "ide-settings" and "manual".
> >>
> >> They aren't part of "main", nor of "test" (which is just the test of
> >> main in the Maven concentions), but they are sources. They aren't the
> >> "resources" of "main" for sure (they would be part of freemarker.jar
> >> otherwise).
> >>
> >> Where should we put them? I believe the current layout follows the
> >> Maven principles, but I can be wrong.
> >>
> >> > Furthermore, the dist directory seems to hold generated artifacts.
> >> > This should go in somewhere under /build no?
> >>
> >> No, src/dist doesn't hold generated artifacts. If you run `ant dist`,
> >> there will be a build/dist, for which it's used as a source.
> >>
> >> > For example in Gradle the directory structure
> >> > under build contains among other directories things like "classes",
> >> "libs",
> >> > "reports", "test-results", and so on.
> >>
> >> Here too (though the subdirectory names differ somewhat).
> >>
> >> > - I got confused by having src inside src, what does that mean? For
> >> example
> >> > .. src/main/misc/id

Re: New committer: Woonsan Ko

[Taher Alkhateeb]

Congrats

On Feb 14, 2017 11:13 AM, "Jacques Le Roux" 
wrote:

> Welcome Woonsan!
>
> Jacques
>
>
> Le 12/02/2017 à 19:42, Daniel Dekany a écrit :
>
>> The Project Management Committee (PMC) for Apache FreeMarker
>> (incubating) has invited Woonsan Ko to become a committer and we are
>> pleased to announce that he has accepted.
>>
>> Woonsan Ko has been an active FreeMarker user for years while using
>> FreeMarker as primary template engine for web content management
>> applications. He is willing to contribute more and help the Apache
>> FreeMarker community more proactively. He is working at Hippo, a
>> BloomReach company, as a lead solution architect. He has been
>> contributing to Apache Portals and Apache Commons SCXML projects as
>> well for years.
>>
>> Being a committer enables easier contribution to the project since
>> there is no need to go via the patch submission process. This should
>> enable better productivity.
>>
>>
>

Re: [VOTE] Which logo?

[Taher Alkhateeb]

Cool work Nicolas,

If I may suggest, perhaps #1 could be improved by having a smaller shadow
that does not extend all the way to the corner, similar to the original
logo. The problems with #1 and #2 is that although the idea is nice, the
shadow pulling all the way to the corner makes it a bit too classic? A
shorter version might look much nicer while preserving the 3D effect?

Just tossing ideas around!

On Mon, Jan 16, 2017 at 4:40 PM, Mauricio Nuñez 
wrote:

> I like #3
>
> Regards,
>
>
> Mauricio
>
> 2017-01-16 9:02 GMT-03:00 :
>
> > I vote for #2, although the 3d effect is overdone.
> >
> > Cheers,
> >
> > -- Denis.
> >   Original Message
> > From: Christoph Rüger
> > Sent: Monday, 16 January 2017 11:27
> > To: Freemarker dev Mailinglist; Daniel Dekany
> > Reply To: dev@freemarker.incubator.apache.org
> > Subject: Re: [VOTE] Which logo?
> >
> > +1 for top row #3
> >
> > I would also like a version of #3 with rounded corners for an app-icon
> > look-and-feel.
> >
> > 2017-01-16 12:11 GMT+01:00 Daniel Dekany :
> >
> > > We will replace our square logo at Twitter
> > > (https://twitter.com/freemarker), and probably will use the same logo
> > > in the future elsewhere too.
> > >
> > > Which one do you prefer from the *top* row (1, 2, 3)?
> > > https://drive.google.com/open?id=0B5BwTaGcWGtNLU0wQmFiUElFc2c
> > >
> > > (The bottom row is for file icons, but currently we won't use them
> > > anywhere.)
> > >
> > > Thanks for Julien Nicolas for providing these!
> > >
> > > --
> > > Thanks,
> > > Daniel Dekany
> > >
> > >
> >
> >
> > --
> > Christoph Rüger, Geschäftsführer
> > Synesty  - Automatisierung, Schnittstellen,
> > Datenfeeds
> > Tel.: +49 3641/559649
> >
> > Xing: https://www.xing.com/profile/Christoph_Rueger2
> > LinkedIn: http://www.linkedin.com/pub/christoph-rueger/a/685/198
> >
> > --
> > Synesty GmbH
> > Moritz-von-Rohr-Str. 1a
> > 07745 Jena
> > Tel.: +49 3641 559649
> > Fax.: +49 3641 5596499
> > Internet: http://synesty.com
> >
> > Geschäftsführer: Christoph Rüger
> > Unternehmenssitz: Jena
> > Handelsregister B beim Amtsgericht: Jena
> > Handelsregister-Nummer: HRB 508766
> > Ust-IdNr.: DE287564982
> >
>

Re: Using Social Media to Help Promote Freemarker

[Taher Alkhateeb]

Hi Denis,

Perhaps we can do that in Gradle since talk was going in another thread of
making a switch. I'm working on a first draft.

On Jan 7, 2017 6:37 PM, "Denis Bredelet"  wrote:


> Le 7 janv. 2017 à 12:36, Daniel Dekany  a écrit :
>
> Saturday, January 7, 2017, 9:37:36 AM, Denis Bredelet wrote:
>
>> Hi Daniel,
>>
 That was also my impression on the OFBiz tweet, as a software
 developer. The last is important, that I'm looking at it as a
 developer. FreeMarker, unless OFBiz, is mostly only interesting for
 them I believe. It doesn't have an UI that a manager type could click
 around. It's not a complete end-user product, it's Java library used
 internally by other products.
>>
>> I am thinking of contributing a very simple UI for FreeMarker.
>> Something able to read a single template and process it with a
>> datamodel pulled from various sources (user interface window, properties
file, XML file…)
>>
>> Would that be useful and help with advertising FreeMarker?
>
> I believe it's something that many users need, because it's not always
> convenient to try things right in the real product that integrates
> FreeMarker. Especially if you just want the wrap your head around
> something you have just read in the Manual. So I was considering
> creating a such GUI, only my priorities (core maintenance) didn't
> allow that. And then suddenly come
> http://freemarker-online.kenshoo.com/, so we do have something like
> that, but it could be improved further, also perhaps an offline
> version (like a SWT application or such) can be handy (if you want to
> connect to a local DB, etc).
>
> These template evaluators are also useful to draw the user's attention
> to best practices and features. Like if you go to
> http://freemarker-online.kenshoo.com/, you will be aware of output
> formats, a relatively novel but very useful feature.
>
>> I have some code to use as a starting point on my website:
>> http://bredelet.com/Denis/FreeMarker%20first%20steps.html
>
> These are some getting started examples. What are your ideas about the
> final product?

I am thinking of adding a « main » function in the FreeMarker JAR to load a
template and a model (as XML or properties, that is why I showed the link).
Then create a separate JAR with the UI to load the template and datamodel
from the filesystem or define a datamodel interactively, and save the
processed template in a file.

Cheers,
— Denis.

>> Maybe this could come as a separate JAR to avoid loading UI classes
unnecessarily.
>
>> Cheers,
>> — Denis.
>
> --
> Thanks,
> Daniel Dekany
>

Re: Gradle for FreeMarker, anyone? (Was: Maven for Freemarker)

[Taher Alkhateeb]

Hi Daniel,

Okay things are much more clear thank you!

With respect to the repository, I guess there are two uses of the word
repository. On one hand it is what you meant (a place to publish your
artifacts) and on another hand it is where you pull your dependencies from
(libraries).

What I mean is the second form (pulling dependencies). Do you want to pull
from MavenCentral, or do you prefer to pull from JCenter? To give you some
perspective on the difference this might be helpful ->
http://stackoverflow.com/questions/24852219/android-buildscript-repositories-jcenter-vs-mavencentral#28457914

Cheers,

Taher Alkhateeb

On Mon, Jan 2, 2017 at 11:29 AM, Daniel Dekany <ddek...@freemail.hu> wrote:

> Monday, January 2, 2017, 8:14:25 AM, Taher Alkhateeb wrote:
>
> > Hi Daniel,
> >
> > Okay thank you for all the feedback. I will start to experiment in code a
> > little bit, but a few more lingering comments / questions:
> >
> > # Comments
> > - Every project optionally ends with a jar, but again, you can tweak that
> > to your liking.
> > - Embedded Ant is pretty clean code (we use it a lot). Ant is a first
> class
> > citizen in Gradle and fully integrated syntax wise (it's not XML)
> > - Your comment on JavaCC is similar to multi-project architecture
> > - Gradle has built-in plugins for both Eclipse and Intellij with quite
> > powerful DSL for customization
> >
> > # Questions
> > - The code directory structure is strange to me. By convention src means
> a
> > directory for all source code in multiple different languages. So it
> could
> > be something like src/main/java src/test/java src/main/groovy etc ...
>
> I have a "javacc" directory on that level, which is a language so it
> fits into this, and "misc" which are the things I don't know here else
> to put, but they still belong to the sources of "main"...
>
> > However, you have other directories that sound to me like "resources" or
> > such rather than src like "ide-settings" and "manual".
>
> They aren't part of "main", nor of "test" (which is just the test of
> main in the Maven concentions), but they are sources. They aren't the
> "resources" of "main" for sure (they would be part of freemarker.jar
> otherwise).
>
> Where should we put them? I believe the current layout follows the
> Maven principles, but I can be wrong.
>
> > Furthermore, the dist directory seems to hold generated artifacts.
> > This should go in somewhere under /build no?
>
> No, src/dist doesn't hold generated artifacts. If you run `ant dist`,
> there will be a build/dist, for which it's used as a source.
>
> > For example in Gradle the directory structure
> > under build contains among other directories things like "classes",
> "libs",
> > "reports", "test-results", and so on.
>
> Here too (though the subdirectory names differ somewhat).
>
> > - I got confused by having src inside src, what does that mean? For
> example
> > .. src/main/misc/identifierChars/src/main/freemarker/adhoc
>
> It's just a Java class used for generating a piece of the actual
> source code. It can only be ran manually, and then you just copy paste
> over its output. It's not used by the build process, but I wanted the
> source be in the VCS. Because it's java, it uses the usual structure
> inside src/main/misc/identifierChars... I'm not sure where to put it.
>
> > - Are you open / wanting to restructure the directory layout to something
> > more conventional, or do you prefer maintaining it? I ask because I think
> > the structure seems a bit unconventional and surprised me when I started
> to
> > look around.
>
> I'm open to improve the layout, but I'm not sure how to make it more
> standard. I mean I think it pretty much is standard. To my
> understanding, things that don't belong to the sources used for
> generating the main Maven artifact (freemarker.jar), should be in
> src/, where  can be anything that doesn't clash
> with "main", "test" and maybe some more common stuff. We might have
> some such subdirectories that aren't common, but they have to be
> somewhere after all.
>
> > - Are you folks actually using OSGI? I can see the file "osgi.bnd" in top
> > level directory. Is this something to worry about?
>
> Yes, many use FreeMarker under OSGi.
>
> > - What is the purpose of build.properties.sample?
>
> To copy it to build.properties and modify it to fit your environment.
> See also Building in the README. I don't know Gradle much, but I think
> gradle.

Re: Gradle for FreeMarker, anyone? (Was: Maven for Freemarker)

[Taher Alkhateeb]

Hi Daniel,

Okay thank you for all the feedback. I will start to experiment in code a
little bit, but a few more lingering comments / questions:

# Comments
- Every project optionally ends with a jar, but again, you can tweak that
to your liking.
- Embedded Ant is pretty clean code (we use it a lot). Ant is a first class
citizen in Gradle and fully integrated syntax wise (it's not XML)
- Your comment on JavaCC is similar to multi-project architecture
- Gradle has built-in plugins for both Eclipse and Intellij with quite
powerful DSL for customization

# Questions
- The code directory structure is strange to me. By convention src means a
directory for all source code in multiple different languages. So it could
be something like src/main/java src/test/java src/main/groovy etc ...
However, you have other directories that sound to me like "resources" or
such rather than src like "ide-settings" and "manual". Furthermore, the
dist directory seems to hold generated artifacts. This should go in
somewhere under /build no? For example in Gradle the directory structure
under build contains among other directories things like "classes", "libs",
"reports", "test-results", and so on.
- I got confused by having src inside src, what does that mean? For example
.. src/main/misc/identifierChars/src/main/freemarker/adhoc
- Are you open / wanting to restructure the directory layout to something
more conventional, or do you prefer maintaining it? I ask because I think
the structure seems a bit unconventional and surprised me when I started to
look around.
- Are you folks actually using OSGI? I can see the file "osgi.bnd" in top
level directory. Is this something to worry about?
- What is the purpose of build.properties.sample?
- Do you have a preference for a remote repo? Jcenter is the biggest (
https://bintray.com/bintray/jcenter), but you might have specific
requirements from MavenCentral?

Too many questions, I know, but I'm having a bit of a challenge trying to
grok the structure of the application because this is the first thing to
define in Gradle (where things are).

Cheers,

Taher Alkhateeb

On Sun, Jan 1, 2017 at 9:40 PM, Daniel Dekany <ddek...@freemail.hu> wrote:

> Sunday, January 1, 2017, 12:32:22 PM, Daniel Dekany wrote:
>
> [snip]
> > Only the final results matter, which are:
> >
> > - freemarker.jar - monolithic (in 2.x.x at least), and note the things
> >   under the META-INF, and the substitutions in version.properties.
> >
> > - Maven source and javadoc artifacts
> >
> > - Manual (HTML genereated via docgen from the XDocBook file)
> >
> > - JavaDoc (with some class exclusions and with Java 8's typographic
> >   nonsense fixed)
> >
> > - Apache release artifacts (src and bin, signed and all, as usual).
> >   Note that the bin release contains the generated Manual and JavaDoc.
> >
> > - Uploading release into the Maven staging repository
> >
> > - Rat report
> >
> > - Ensure that the project works with Eclipse fine (and with IntelliJ
> >   ideally, but frankly I don't even know if the current one works with
> >   that well). In the README there's a detailed description of how to
> >   set up Eclipse, where you can describe the necessary steps.
> [snip]
>
> And have forgotten one:
>
> - Running the tests
>
> --
> Thanks,
>  Daniel Dekany
>
>

Re: Gradle for FreeMarker, anyone? (Was: Maven for Freemarker)

[Taher Alkhateeb]

Hello Everyone,

We recently switched Apache OFBiz from Ant to Gradle and it was an 
amazing experience. I was the main developer working on the transition 
and I think if something so complex and wired up with hundreds of 
libraries like OFBiz can do it, then I think it would be a much more 
pleasant experience with FreeMarker.


Transitioning to Gradle, however, requires a shift of the way you think, 
it is not an imperative style of "do this then do that" and it has 
multiple build phases (initialization, configuration and execution). 
Gradle is also subject to frequent changes more than ant or Maven. For 
example, in versions 3+ the left shift operator "<<" was deprecated even 
though heavily used in projects and is subject for total removal in 
version 5.


Overall, I would say between the three build systems, Gradle is the most 
powerful hands down as it mixes the convention-over-configuration 
philosophy of maven while at the same time allowing overriding any 
configuration setting. It also provides a powerful DSL on top of a full 
programming language (Groovy)


If you folks would like to proceed with the transition, and need extra 
hands, I'd love to help however I can.


Cheers,

Taher Alkhateeb


On 2016-12-31 02:43 (+0300), Daniel Dekany <d...@freemail.hu> wrote:
> Friday, December 30, 2016, 11:44:35 PM, Apache wrote:>
>
> > I\u2019m not sure what \u201cfuture-proof\u201d means.>
>
> By that I mean that if we have to do something non-standard, it's>
> probably easier to achieve with Gradle.>
>
> Also, if we include FM2 in this, then we surely has to do non-standard>
> things. In FM2 the resulting freemarker.jar has to be the same>
> monolithic jar, etc.>
>
> Last not least, if someone is interested in Gradle, and so wants to>
> tackle this task, then I believe we should just go for Gradle.>
> Especially as it can be started right now with FM2, while with Maven,>
> he had to wait until FM3 gets somewhere.>
>
> -- >
> Thanks,>
> Daniel Dekany>
>
>
> > Maven is basically the standard the other build tools have to be>
> > compatible with. The Maven team has been discussing ways to enhance>
> > the pom.xml to open up new features for quite some time and do seem>
> > to be making some progress.>
> >>
> > The big downside with an Ant build is that everything is custom.>
> > Maven takes the opposite approach - everything is standard, while>
> > Gradle is somewhere in the middle.>
> >>
> > Ralph>
> >>
> >> On Dec 30, 2016, at 2:05 PM, Daniel Dekany <dd...@freemail.hu> 
wrote:>

> >> >
> >> I think recreating the Ant build of FM 2 in Gradle (with nearly>
> >> identical output) would be a good start. For starters, it's useful 
in>

> >> itself, like it makes FM 2 look less ancient. (-; It's parhaps also>
> >> useful if we want to become Android friendly. Then, it will be 
easier>

> >> to proceed with a modular Gradle build in FM 3. (I'm leaning towards>
> >> Gradle as opposed to Maven because it gives us more flexibility, so>
> >> it's more future proof. As history has shown, FreeMarker often needs>
> >> that.)>
> >> >
> >> If you or anyone else feels like playing with the FM2 Ant to Gradle>
> >> conversion, go ahead!>
> >> >
> >> >
> >> Thursday, September 22, 2016, 1:08:18 PM, Mauricio Nu%uFFFDez wrote:>
> >> >
> >>> Hi Daniel,>
> >>> >
> >>> Thanks for your feedback. I'm pushing to my personal github. I 
have a>
> >>> parent pom with a submodule core and a submodule ext. I want to 
check>

> >>> alternatives for the different artifacts. Maybe with reflection, as>
> >>> suggested by the previous effort, or retrotranslator.>
> >>> >
> >>> https://github.com/mauronunez/incubator-freemarker/tree/maven ( 
my fork,>

> >>> branch "maven" )>
> >>> >
> >>> I have more experience with maven, but I think this as 
intermediate step>

> >>> for Gradle.>
> >>> About maven for FM2, yes, I agree with to keep it as is, not 
impacting>
> >>> users. I want to contribute my changes to FM3, but now, FM2 it's 
a good>

> >>> codebase to test, and to be more involved as developer.>
> >>> >
> >>> Btw, I've create a pull request to fix some Junit tests.>
> >>> >
> >>> Regards,>
> >>> >
> >>> Mauricio>
> >>> >
> >>> 20