Maven for Freemarker

2016-09-20 Thread Mauricio Nuñez
Hi all,

I'm a older user of freemarker, from version 1. Today, I'm working in a
maven pom.xml  for freemarker. Freemarker is very valuable for me, and I
want to contribute. My old web site ( www.chile.com )  is down now, but it
was developed with freemarker about 2002-2003.

I'm using a maven plugin for javacc, and this build is working. I have some
issues with some JUnit tests, but I'm working in that ( I guess the problem
is related to my Locale )

But my approach is to create a base freemarker project, and a second
project, related to extensions ( jython, servlet, etc ). Before continue, I
want some comments from you.

Regards,

Mauricio


Re: Maven for Freemarker

2016-09-22 Thread Mauricio Nuñez
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

2016-09-21 14:49 GMT-03:00 Daniel Dekany :

> Hi,
>
> In FreeMarker 3 we want to modularize the project, so that there will
> be at least a freemarker-core and then a separate artifacts for each
> extension (like freemarker-jsp, etc.). Thus so far I agree with what
> you are doing. If it can be done with FreeMarker 2 though, I'm not
> sure, because we have to keep strict backward compatibility there, and
> also we have to consider how much hassle such a change causes for the
> users. (There are orders magnitude more users than contributors.
> Something that's nice for the contributors might bears no value for
> the users, or even just makes dependency management more fragile for
> them.)
>
> As of a monolithic Maven build (where the point is to migrate away
> from Ant and make the build more "standard"), there was such activity,
> but it didn't get far enough so far:
> https://issues.apache.org/jira/browse/FREEMARKER-7?jql=
> project%20%3D%20FREEMARKER
>
> The main problem is that in FreeMarker it happens now and then that we
> have to depend on multiple versions of the same artifact (or on
> multiple versions of the Java platform). Ant can handle that, but
> Maven... well, perhaps if we extract parts that are above the baseline
> platform (Java 5 currently, but let's say Java 6) into separate
> artifacts, like freemarker-core-java-8 and such, but that won't be
> backward compatible as users had to depend on them explicitly (I
> guess), and even if we consider FreeMarker 3, it might complicates the
> life of users. So perhaps we have to look into using Gradle. (Gradle
> can be also handy if we want to target Android, and with in FreeMarker
> 3 we surely should.)
>
> Also, there are quite a few extra steps and extra tasks, if you look
> into the build.xml. Though I guess most of them can be reimplemented
> in Maven gradually, and we can keep the Ant build until it's done...
>
>
> Tuesday, September 20, 2016, 10:03:56 PM, Mauricio Nuñez wrote:
>
> > Hi all,
> >
> > I'm a older user of freemarker, from version 1. Today, I'm working in a
> > maven pom.xml  for freemarker. Freemarker is very valuable for me, and I
> > want to contribute. My old web site ( www.chile.com )  is down now, but
> it
> > was developed with freemarker about 2002-2003.
> >
> > I'm using a maven plugin for javacc, and this build is working. I have
> some
> > issues with some JUnit tests, but I'm working in that ( I guess the
> problem
> > is related to my Locale )
> >
> > But my approach is to create a base freemarker project, and a second
> > project, related to extensions ( jython, servlet, etc ). Before
> continue, I
> > want some comments from you.
> >
> > Regards,
> >
> > Mauricio
>
> --
> Thanks,
>  Daniel Dekany
>
>


Re: Maven for Freemarker

2016-09-23 Thread Mauricio Nuñez
David,

Thanks you, I will check Moqui and Ofbiz to learn about Gradle usage. I
want to dedicate some time to apply this to FM, as a proposal, considering
Daniel's comments.

Regards,

Mauricio

2016-09-22 15:33 GMT-03:00 David E Jones :

>
> I've been using Gradle extensively for a few years now and it's a great
> tool. Basic builds following standard Maven directory
> structures are very easy, but it is flexible enough to do anything you can
> imagine (from my experience so far anyway...).
>
> Dependency management is very good, with lots of options to manage
> transitive dependencies and such. There is even a handy plugin to
> check for updates to dependencies. More generally the combination of
> scripting tasks using Groovy and a wide variety of plugins
> makes it a very powerful tool. I imagine a lot of the same things can be
> done with Maven, but I doubt as much or as conveniently (I
> don't have as much experience with highly custom Maven builds to compare
> though).
>
> Gradle allows you to set the Java version to compile for
> (targetCompatibility and sourceCompatibility fields), and though I haven't
> tried it you should be able to build for multiple Java versions with no
> issues in different modules or maybe even in the same module
> with different build tasks.
>
> There is pretty good support for running ant tools as well, a nice
> fallback for things that are easier in Ant. I used that quite a
> bit early on with Gradle, but rarely do so now as Gradle has good ways of
> doing most anything.
>
> One downside to Gradle is that it is much heavier than Ant in terms of
> system resources on your dev machine. For me this isn't
> generally a big deal, and while the Gradle Daemon makes stuff build just
> as fast as Ant it hogs some memory (only an issue on my
> little travel laptop which has more limited memory).
>
> I don't think this sort of thing will be a big deal for FreeMarker, but in
> Moqui Framework (and more recently in Apache OFBiz)
> Gradle is used to handle more complex multi-module builds including
> handling modules dropped in and 'auto discovered' using a little
> method in the settings.gradle file, plus in Moqui things like
> automatically getting dependent components (a framework level thing,
> not a Java thing) using configuration in XML files that are framework
> specific using the convenient XML parsing and such that is
> part of Groovy.
>
> In short I'd highly recommend Gradle. The documentation for the API and
> such is good and these days there are lots of people using
> it so there are many plugins available and you can find solutions to just
> about anything with a little googling.
>
> -David
>
>
> On Wed, 2016-09-21 at 19:49 +0200, Daniel Dekany wrote:
> > Hi,
> >
> > In FreeMarker 3 we want to modularize the project, so that there will
> > be at least a freemarker-core and then a separate artifacts for each
> > extension (like freemarker-jsp, etc.). Thus so far I agree with what
> > you are doing. If it can be done with FreeMarker 2 though, I'm not
> > sure, because we have to keep strict backward compatibility there, and
> > also we have to consider how much hassle such a change causes for the
> > users. (There are orders magnitude more users than contributors.
> > Something that's nice for the contributors might bears no value for
> > the users, or even just makes dependency management more fragile for
> > them.)
> >
> > As of a monolithic Maven build (where the point is to migrate away
> > from Ant and make the build more "standard"), there was such activity,
> > but it didn't get far enough so far:
> > https://issues.apache.org/jira/browse/FREEMARKER-7?jql=
> project%20%3D%20FREEMARKER
> >
> > The main problem is that in FreeMarker it happens now and then that we
> > have to depend on multiple versions of the same artifact (or on
> > multiple versions of the Java platform). Ant can handle that, but
> > Maven... well, perhaps if we extract parts that are above the baseline
> > platform (Java 5 currently, but let's say Java 6) into separate
> > artifacts, like freemarker-core-java-8 and such, but that won't be
> > backward compatible as users had to depend on them explicitly (I
> > guess), and even if we consider FreeMarker 3, it might complicates the
> > life of users. So perhaps we have to look into using Gradle. (Gradle
> > can be also handy if we want to target Android, and with in FreeMarker
> > 3 we surely should.)
> >
> > Also, there are quite a few extra steps and extra tasks, if you look
> > into the build.xml. Though I guess most of

Re: Including an external file in a template

2016-10-18 Thread Mauricio Nuñez
Hi,

Importing files is related to configuration. You can load files ( with and
without parsing ) from anywhere ( assuming you are aware of the security
implications )

http://freemarker.org/docs/pgui_config_templateloading.html#autoid_41

http://freemarker.org/docs/ref_directive_include.html

Regards,

M

2016-10-18 11:03 GMT-03:00 John D. Ament :

> Hi,
>
> Suppose I have a local .txt file.  Is there an easy way that I can import
> the contents of this file?
>
> John
>


Re: [FM3] Drop ext.jython, ext.javascript, ext.jdom

2017-01-12 Thread Mauricio Nuñez
Hi,

I agree with a minimal FM3 core and 3rd party dependencies/integrations in
extra modules. Maybe a secondary repository or project, like FM3-extras,
separated from the main site.

Regards,

Mauricio


2017-01-12 10:56 GMT-03:00 Daniel Dekany :

> As far as I know these aren't used much anymore. So I suggest we drop
> them from FM3 (which isn't compatible with FM2 anyway). They would be
> moved to separate Maven modules (jar-s like freemarker-jython)
> otherwise. (If it ever turns out that people miss them in FM3, we can
> always add a such module later.)
>
> Any objections/thoughts?
>
> --
> Thanks,
>  Daniel Dekany
>
>


Re: [FM3] Drop ext.jython, ext.javascript, ext.jdom

2017-01-13 Thread Mauricio Nuñez
Well, FM3 can be reduced to a minimum, core and servlet ( IMHO ), dropping
those dependencies.

The different integrations can be managed outside of freemarker, ideally
motivating new projects managed by new people. Just dreaming, but  for
example, think in an scala-freemarker , clojure-freemarker, o
nashorn-freemarker integrations.

Regards,



2017-01-12 11:50 GMT-03:00 Daniel Dekany :

> The question here meant to be if we can *totally* get rid of those in
> the subject in FM3.
>
> Otherwise, yes, there's a consensus regarding the modularity thing,
> i.e., to have a quite minimal core (whether we call that
> o.a.f:freemarker or o.a.f:freemarker-core, not decided yet) and then
> additional modules like o.a.f:freemarker-servlet.
>
>
> Thursday, January 12, 2017, 3:10:36 PM, Mauricio Nuñez wrote:
>
> > Hi,
> >
> > I agree with a minimal FM3 core and 3rd party dependencies/integrations
> in
> > extra modules. Maybe a secondary repository or project, like FM3-extras,
> > separated from the main site.
> >
> > Regards,
> >
> > Mauricio
> >
> >
> > 2017-01-12 10:56 GMT-03:00 Daniel Dekany :
> >
> >> As far as I know these aren't used much anymore. So I suggest we drop
> >> them from FM3 (which isn't compatible with FM2 anyway). They would be
> >> moved to separate Maven modules (jar-s like freemarker-jython)
> >> otherwise. (If it ever turns out that people miss them in FM3, we can
> >> always add a such module later.)
> >>
> >> Any objections/thoughts?
> >>
> >> --
> >> Thanks,
> >>  Daniel Dekany
> >>
> >>
>
> --
> Thanks,
>  Daniel Dekany
>
>


Re: [VOTE] Which logo?

2017-01-16 Thread Mauricio Nuñez
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: Confluence Wiki Administrators

2017-01-17 Thread Mauricio Nuñez
I want to help. My user is : mauronunez

Regards

2017-01-10 11:05 GMT-03:00 Sharan Foga :

> Hi Daniel
>
> I have updated the request to include you.
>
> Thanks
> Sharan
>
>
> On 10/01/17 15:02, Daniel Dekany wrote:
>
>> Tuesday, January 10, 2017, 1:52:58 PM, Sharan Foga wrote:
>>
>> Hi All
>>>
>>> As part of the Infra request for the confluence wiki, I'll need the
>>> name of a person (or people) to administer the wiki for the project.
>>> It's good to have a few people so there is backup. I'm happy to
>>> volunteer  – is  anyone else interested in being a wiki
>>> administrator? (If so then please respond and include your
>>> confluence username as I'll need it for the infra request).
>>>
>> Yes, add me please. The user name is ddekany.
>>
>> Thanks
>>> Sharan
>>>
>>>
>


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

2017-02-14 Thread Mauricio Nuñez
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.

Regards,

Mauricio



2017-02-14 15:39 GMT-03:00 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 
> 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 
> > 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 sur

Re: New ASF Member from FreeMarker Community

2017-04-05 Thread Mauricio Nuñez
Great news!

El abr. 5, 2017 5:22 AM, "Taher Alkhateeb" 
escribió:

> Congratulations :) Wishing you all the best.
>
> On Wed, Apr 5, 2017 at 10:12 AM, Sharan Foga  wrote:
>
> > Well done and congratulations Daniel!
> >
> > Thanks
> > Sharan
> >
> > On 2017-04-05 09:09 (+0200), Jacopo Cappellato <
> > jacopo.cappell...@gmail.com> wrote:
> > > Good news: Daniel Dekany from the FreeMarker community has been invited
> > to
> > > become member of the Apache Software Foundation.
> > >
> > > Many congratulations Daniel!!!
> > >
> > > Jacopo
> > >
> >
>


Test fails with locale using comma as decimal separator

2018-01-22 Thread Mauricio Nuñez
Hi!

I've created a PR ( 1 line ).
With my local setup ( es_CL ) , the test suite is reporting an error.
My approach is to define a fixed locale for that test execution.

https://github.com/apache/incubator-freemarker/pull/43

Regards,

Mauricio


Re: Test fails with locale using comma as decimal separator

2018-01-22 Thread Mauricio Nuñez
Tested! It's working now without my patch.

Regards!



2018-01-22 11:46 GMT-03:00 Daniel Dekany :

> Good catch, however, I rather fix this kind of problem at its root,
> and initialize the locale to en_US, and also the time zone etc., for
> all "templatesuite" tests (see my commit). Can you confirm that now
> the test passes without your patch?
>
>
> Monday, January 22, 2018, 2:16:08 PM, Mauricio Nuñez wrote:
>
> > Hi!
> >
> > I've created a PR ( 1 line ).
> > With my local setup ( es_CL ) , the test suite is reporting an error.
> > My approach is to define a fixed locale for that test execution.
> >
> > https://github.com/apache/incubator-freemarker/pull/43
> >
> > Regards,
> >
> > Mauricio
>
> --
> Thanks,
>  Daniel Dekany
>
>


Re: FreeMarker has graduated to TLP!

2018-03-24 Thread Mauricio Nuñez
Great news. Congratulations! This is a tool I've recommended by years, and
now this confirm my election :-)

Regards!

2018-03-24 6:05 GMT-03:00 :

> Congratulations!
> ...and I am happy to because we use freemarker every day.
>
>
> -Ursprüngliche Nachricht-
> Von: Daniel Dekany 
> Gesendet: Freitag, 23. März 2018 21:00
> An: dev@freemarker.incubator.apache.org
> Betreff: FreeMarker has graduated to TLP!
>
> To quote the relevant part from the ASF Board Meeting Summary of March 21,
> 2018:
>
>   The following resolutions were passed unanimously:
>
> A. Establish the Apache FreeMarker Project (Dániel Dékány VP)
>
> So now that this uncertainty was eliminated, we can feel much more
> motivated
> to push FM ahead. We were awarded with the additional trust associated to
> the "Apache" brand, so let's put code behind it that fits the modern
> standards, by which I mean FM3. Of course, FM2 also needs to be maintained,
> even receive new features. But I believe FM3 is absolutely necessary for
> growth, adoption in new projects.
>
> It will take a while until all the "paper work" and infrastructural changes
> are done (https://incubator.apache.org/guides/transferring.html). But we
> don't have to wait for all of that to release 2.3.28 as non-incubating, so
> I
> hope that will be done sometimes next week.
>
> --
> Thanks,
>  Daniel Dekany
>
>
>