from:"Jacques Le Roux"

Re: Please test/review 2.3.34-SNAPSHOT

2024-10-19 Thread Jacques Le Roux

We have created a new release branch, its 1st release should not be before
months, so no.
Maybe the the community will like to put in this new release branch, not sure.

So no, nothing is pushing us, was just to know, take it easy :)

Thanks

Le 19/10/2024 à 02:19, Daniel Dekany a écrit :

Not this weekend either... but it starts to bother me quite much, so
eventually... But, why, is there a OFBiz release to catch?

On Fri, Oct 18, 2024 at 12:19 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Daniel,

Any chances ?

TIA

Jacques

Le 22/09/2024 à 15:08, Daniel Dekany a écrit :

Haven't put the time into it yet... but, yes, I should push this. Maybe
next weekend I will start voting. Will see.

On Sun, Sep 22, 2024 at 1:22 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,

What is the situation here?

TIA

Jacques

Le 29/08/2024 à 09:37, Jacques Le Roux a écrit :

Hi,

With https://issues.apache.org/jira/browse/OFBIZ-13131 I have

committed

https://github.com/apache/ofbiz-framework/commit/9d43c4dd5e to test the

change toward 2.3.34-SNAPSHOT

It's now a week, and checking daily the OFBiz trunk demo error.log I

did

not find any related issue.

So it's OK with me to release 2.3.34

Jacques

Le 22/08/2024 à 08:40, Jacques Le Roux a écrit :

Ah, I did not know that. Then we can backport. I'll not it in the

Jira.

Thanks

Le 21/08/2024 à 23:34, Daniel Dekany a écrit :

OK, thanks!

I'm not getting why the Java version is relevant though.

Multi-release

JAR

format was introduced with Java 9 (and Java 8 will just ignore the

directories inside META-INF, so we are also Java 8 compatible.)

On Wed, Aug 21, 2024 at 10:17 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Le 19/08/2024 à 14:01, Daniel Dekany a écrit :

While we have not much changes accumulated yet, the tooling related
issues with 2.3.33 freemarker.jar (see below) warrants an urgent
release.

The current change log of 2.3.34 is this:

https://freemarker.apache.org/builds/2.3.34-SNAPSHOT/_html/versions_2_3_34.html

Latest build is published to the Apache snapshot repo:

https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.34-SNAPSHOT/

About the tooling related issues: 2.3.33 freemarker.jar contains

class

files compiled with various Java versions (8, 9, and 16). In

theory,

that should work, but is unusual. It turns out, Maven Enforcer, and
apparently GraalVM Native complains about it. Maybe other tools

have

problems with it too. So we switched to "multi-release JAR" (JEP

238)

format, which is the clean and official solution for our problem
anyway. However, that's not a very well-known Java feature, and I

can

imagine that proper support for it is spotty. So, does it work with
your tooling (like does the build issue warnings)? Does it work in
your runtime environment (print the return value of
_Java9.isSupported(), and _Java16.isSupported() to see, also if you
are using record support successfully, that's another proof that

it's

still working)?

Also note in the README that ad-hoc "main" methods from the IDE

won't

work properly anymore, and you have to create a JUnit test instead.

Thanks for any help!

Hi Daniel,

We (OFBiz community) have started testing with
https://issues.apache.org/jira/browse/OFBIZ-13131

We use Java 17 in trunk, I don't think we will backport in our

current

stable version (18.12 branch) because it uses Java 11 and 2.3.33 is

quite

For now we did not cross any issues.

Thanks

Jacques

Re: Please test/review 2.3.34-SNAPSHOT

2024-10-18 Thread Jacques Le Roux

Hi Daniel,

Any chances ?

TIA

Jacques

Le 22/09/2024 à 15:08, Daniel Dekany a écrit :

Haven't put the time into it yet... but, yes, I should push this. Maybe
next weekend I will start voting. Will see.

On Sun, Sep 22, 2024 at 1:22 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,

What is the situation here?

TIA

Jacques

Le 29/08/2024 à 09:37, Jacques Le Roux a écrit :

Hi,

With https://issues.apache.org/jira/browse/OFBIZ-13131 I have committed

https://github.com/apache/ofbiz-framework/commit/9d43c4dd5e to test the

change toward 2.3.34-SNAPSHOT

It's now a week, and checking daily the OFBiz trunk demo error.log I did

not find any related issue.

So it's OK with me to release 2.3.34

Jacques

Le 22/08/2024 à 08:40, Jacques Le Roux a écrit :

Ah, I did not know that. Then we can backport. I'll not it in the Jira.

Thanks

Le 21/08/2024 à 23:34, Daniel Dekany a écrit :

OK, thanks!

I'm not getting why the Java version is relevant though. Multi-release

JAR

format was introduced with Java 9 (and Java 8 will just ignore the

directories inside META-INF, so we are also Java 8 compatible.)

On Wed, Aug 21, 2024 at 10:17 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Le 19/08/2024 à 14:01, Daniel Dekany a écrit :

While we have not much changes accumulated yet, the tooling related
issues with 2.3.33 freemarker.jar (see below) warrants an urgent
release.

The current change log of 2.3.34 is this:

https://freemarker.apache.org/builds/2.3.34-SNAPSHOT/_html/versions_2_3_34.html

Latest build is published to the Apache snapshot repo:

https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.34-SNAPSHOT/

About the tooling related issues: 2.3.33 freemarker.jar contains

class

files compiled with various Java versions (8, 9, and 16). In theory,
that should work, but is unusual. It turns out, Maven Enforcer, and
apparently GraalVM Native complains about it. Maybe other tools have
problems with it too. So we switched to "multi-release JAR" (JEP 238)
format, which is the clean and official solution for our problem
anyway. However, that's not a very well-known Java feature, and I

can

Also note in the README that ad-hoc "main" methods from the IDE won't
work properly anymore, and you have to create a JUnit test instead.

Thanks for any help!

Hi Daniel,

We (OFBiz community) have started testing with
https://issues.apache.org/jira/browse/OFBIZ-13131

We use Java 17 in trunk, I don't think we will backport in our current
stable version (18.12 branch) because it uses Java 11 and 2.3.33 is

quite

For now we did not cross any issues.

Thanks

Jacques

Re: Please test/review 2.3.34-SNAPSHOT

2024-09-22 Thread Jacques Le Roux

Hi,

What is the situation here?

TIA

Jacques

Le 29/08/2024 à 09:37, Jacques Le Roux a écrit :

Hi,

With https://issues.apache.org/jira/browse/OFBIZ-13131 I have committed https://github.com/apache/ofbiz-framework/commit/9d43c4dd5e to test the
change toward 2.3.34-SNAPSHOT

It's now a week, and checking daily the OFBiz trunk demo error.log I did not
find any related issue.

So it's OK with me to release 2.3.34

Jacques

Le 22/08/2024 à 08:40, Jacques Le Roux a écrit :

Ah, I did not know that. Then we can backport. I'll not it in the Jira.

Thanks

Le 21/08/2024 à 23:34, Daniel Dekany a écrit :

OK, thanks!

I'm not getting why the Java version is relevant though. Multi-release JAR
format was introduced with Java 9 (and Java 8 will just ignore the related
directories inside META-INF, so we are also Java 8 compatible.)

On Wed, Aug 21, 2024 at 10:17 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Le 19/08/2024 à 14:01, Daniel Dekany a écrit :

While we have not much changes accumulated yet, the tooling related
issues with 2.3.33 freemarker.jar (see below) warrants an urgent
release.

The current change log of 2.3.34 is this:

https://freemarker.apache.org/builds/2.3.34-SNAPSHOT/_html/versions_2_3_34.html

Latest build is published to the Apache snapshot repo:

https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.34-SNAPSHOT/

About the tooling related issues: 2.3.33 freemarker.jar contains class
files compiled with various Java versions (8, 9, and 16). In theory,
that should work, but is unusual. It turns out, Maven Enforcer, and
apparently GraalVM Native complains about it. Maybe other tools have
problems with it too. So we switched to "multi-release JAR" (JEP 238)
format, which is the clean and official solution for our problem
anyway. However, that's not a very well-known Java feature, and I can
imagine that proper support for it is spotty. So, does it work with
your tooling (like does the build issue warnings)? Does it work in
your runtime environment (print the return value of
_Java9.isSupported(), and _Java16.isSupported() to see, also if you
are using record support successfully, that's another proof that it's
still working)?

Also note in the README that ad-hoc "main" methods from the IDE won't
work properly anymore, and you have to create a JUnit test instead.

Thanks for any help!

Hi Daniel,

We (OFBiz community) have started testing with
https://issues.apache.org/jira/browse/OFBIZ-13131

We use Java 17 in trunk, I don't think we will backport in our current
stable version (18.12 branch) because it uses Java 11 and 2.3.33 is quite
OK

For now we did not cross any issues.

Thanks

Jacques

Re: Please test/review 2.3.34-SNAPSHOT

2024-08-29 Thread Jacques Le Roux

Hi,

With https://issues.apache.org/jira/browse/OFBIZ-13131 I have committed https://github.com/apache/ofbiz-framework/commit/9d43c4dd5e to test the change
toward 2.3.34-SNAPSHOT

It's now a week, and checking daily the OFBiz trunk demo error.log I did not
find any related issue.

So it's OK with me to release 2.3.34

Jacques

Le 22/08/2024 à 08:40, Jacques Le Roux a écrit :

Ah, I did not know that. Then we can backport. I'll not it in the Jira.

Thanks

Le 21/08/2024 à 23:34, Daniel Dekany a écrit :

OK, thanks!

On Wed, Aug 21, 2024 at 10:17 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Le 19/08/2024 à 14:01, Daniel Dekany a écrit :

While we have not much changes accumulated yet, the tooling related
issues with 2.3.33 freemarker.jar (see below) warrants an urgent
release.

The current change log of 2.3.34 is this:

https://freemarker.apache.org/builds/2.3.34-SNAPSHOT/_html/versions_2_3_34.html

Latest build is published to the Apache snapshot repo:

https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.34-SNAPSHOT/

Also note in the README that ad-hoc "main" methods from the IDE won't
work properly anymore, and you have to create a JUnit test instead.

Thanks for any help!

Hi Daniel,

We (OFBiz community) have started testing with
https://issues.apache.org/jira/browse/OFBIZ-13131

We use Java 17 in trunk, I don't think we will backport in our current
stable version (18.12 branch) because it uses Java 11 and 2.3.33 is quite
OK

For now we did not cross any issues.

Thanks

Jacques

Re: Please test/review 2.3.34-SNAPSHOT

2024-08-21 Thread Jacques Le Roux

Ah, I did not know that. Then we can backport. I'll not it in the Jira.

Thanks

Le 21/08/2024 à 23:34, Daniel Dekany a écrit :

OK, thanks!

On Wed, Aug 21, 2024 at 10:17 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Le 19/08/2024 à 14:01, Daniel Dekany a écrit :

While we have not much changes accumulated yet, the tooling related
issues with 2.3.33 freemarker.jar (see below) warrants an urgent
release.

The current change log of 2.3.34 is this:

https://freemarker.apache.org/builds/2.3.34-SNAPSHOT/_html/versions_2_3_34.html

Latest build is published to the Apache snapshot repo:

https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.34-SNAPSHOT/

Also note in the README that ad-hoc "main" methods from the IDE won't
work properly anymore, and you have to create a JUnit test instead.

Thanks for any help!

Hi Daniel,

We (OFBiz community) have started testing with
https://issues.apache.org/jira/browse/OFBIZ-13131

We use Java 17 in trunk, I don't think we will backport in our current
stable version (18.12 branch) because it uses Java 11 and 2.3.33 is quite
OK

For now we did not cross any issues.

Thanks

Jacques

Re: Please test/review 2.3.34-SNAPSHOT

2024-08-21 Thread Jacques Le Roux

Le 19/08/2024 à 14:01, Daniel Dekany a écrit :

While we have not much changes accumulated yet, the tooling related
issues with 2.3.33 freemarker.jar (see below) warrants an urgent
release.

The current change log of 2.3.34 is this:
https://freemarker.apache.org/builds/2.3.34-SNAPSHOT/_html/versions_2_3_34.html

Latest build is published to the Apache snapshot repo:
https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.34-SNAPSHOT/

Also note in the README that ad-hoc "main" methods from the IDE won't
work properly anymore, and you have to create a JUnit test instead.

Thanks for any help!

Hi Daniel,

We (OFBiz community) have started testing with
https://issues.apache.org/jira/browse/OFBIZ-13131

We use Java 17 in trunk, I don't think we will backport in our current stable
version (18.12 branch) because it uses Java 11 and 2.3.33 is quite OK

For now we did not cross any issues.

Thanks

Jacques

Re: Board report draft for August

2024-08-14 Thread Jacques Le Roux


Hi Daniel,

Sounds good to me

Thanks

Jacques

Le 14/08/2024 à 09:37, Daniel Dekany a écrit :

The draft of the board report, due today(ish), is here:
https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft+-+August+2024

Anything you wanted to add or change?

Re: [VOTE] Release Apache FreeMarker 2.3.33

2024-05-08 Thread Jacques Le Roux


+1

Thanks Daniel !

Le 09/05/2024 à 01:36, Daniel Dekany a écrit :

Hi all,

Please vote on releasing FreeMarker 2.3.33!

Release Notes:
https://freemarker.apache.org/builds/2.3.33-voting/_html/versions_2_3_33.html

Before proceed, you should know that FreeMarker 2.3.x, for a long
time, always releases a normal and a "gae" variant on the same time,
which are technically two independent source trees (Git branches). The
"gae" variant contains a few small modification in the Java source
code to be Google App Engine compliant, and has freemarker-gae as the
Maven artifact name. Otherwise the normal and the "gae" branches are
identical. Hence they will be voted on together.

The commits to be voted upon are:
- Normal (non-gae) variant:
   
https://github.com/apache/freemarker/commit/46c927cdd9409405cb006c0f8ad6d9d41c167878
   Commit hash: 46c927cdd9409405cb006c0f8ad6d9d41c167878
- "gae" variant:
   
https://github.com/apache/freemarker/commit/cf3da59be93ac05de5ceb556c94499b296553509
   Commit hash: cf3da59be93ac05de5ceb556c94499b296553509

The artifacts to be voted upon are located here:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.33/source/
where the source release artifacts are:
- Normal (non-gae) variant:
   apache-freemarker-src-2.3.33.tar.gz
- "gae" variant:
   apache-freemarker-gae-src-2.3.33.tar.gz

See the "Building FreeMarker" section of the README.md inside them for
build instructions!
As described there:
- You need to add the gradle-wrapper.jar manually
- You need multiple JDK versions installed, on locations where Gradle
will find them
- You may need freemarker.allowUnsignedReleaseBuild=true for building
everything (not just the jar)

The release artifacts are signed with the following key:
https://people.apache.org/keys/committer/ddekany.asc

For convenience, we also provide binaries, which also need to be checked:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.33/binaries/
and Maven artifacts in the ASF Staging Repository:
https://repository.apache.org/content/repositories/staging/org/freemarker/freemarker/2.3.33/

Please try out the package and vote!

The vote is open for a minimum of 72 hours or until the necessary number of
votes (3 binding +1s) is reached.

[ ] +1 Release this package as Apache FreeMarker 2.3.33
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...

Please add "(binding)" if your vote is binding.

--
Thanks,
  Daniel Dekany

Re: 2.3.33 pre-vote testing

2024-04-11 Thread Jacques Le Roux

Thanks Daniel,

Jacques

Le 11/04/2024 à 10:31, Daniel Dekany a écrit :

Fix published to the snapshot repo.

On Wed, Apr 10, 2024 at 2:27 PM Daniel Dekany wrote:

Indeed, that convenience method was missed. Will fix that... when I
get there, like hopefully in a day or so. (One can still just use
config.setTemplateLoader(new
freemarker.ext.jakarta.servlet.WebappTemplateLoader(...)) though).

On Wed, Apr 10, 2024 at 11:03 AM Jacques Le Roux
wrote:

Hi,

It seems we found an issue that could be related to
https://issues.apache.org/jira/browse/FREEMARKER-218

It's at bottom of https://issues.apache.org/jira/browse/OFBIZ-12935

TIA

Jacques

Le 12/03/2024 à 11:16, Jacques Le Roux a écrit :

Hi Daniel,

We have started testing with https://issues.apache.org/jira/browse/OFBIZ-12934.

For now we only crossed things to change in OFBiz that makes sense.

We will let you informed in case we cross real issues.

Thanks

Jacques

Le 12/03/2024 à 01:18, Daniel Dekany a écrit :

By the way... if there are bugs, behavior can change with the Java
version, the break points being Java 8, Java 9, and Java 16 (or just
17, as that's what's widely used in reality).

On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger wrote:

No regressions in our test suite.

Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
daniel.dek...@gmail.com>:

Please test if the next release breaks anything. Then if it looks
right, I will update building instructions, and do other more boring
checks (distro zip contents, etc), and start a release voting.

Change log:

https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html

Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache
*snapshot* Maven repo only:

apache-snapshot-repository

https://repository.apache.org/content/repositories/snapshots/
false
true

(Of course you can also download the jar directly, but be careful to
pick the latest:

https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/
)

--
Best regards,
Daniel Dekany

Re: 2.3.33 pre-vote testing

2024-04-10 Thread Jacques Le Roux

Hi,

It seems we found an issue that could be related to
https://issues.apache.org/jira/browse/FREEMARKER-218

It's at bottom of https://issues.apache.org/jira/browse/OFBIZ-12935

TIA

Jacques

Le 12/03/2024 à 11:16, Jacques Le Roux a écrit :

Hi Daniel,

We have started testing with https://issues.apache.org/jira/browse/OFBIZ-12934.

For now we only crossed things to change in OFBiz that makes sense.

We will let you informed in case we cross real issues.

Thanks

Jacques

Le 12/03/2024 à 01:18, Daniel Dekany a écrit :

By the way... if there are bugs, behavior can change with the Java
version, the break points being Java 8, Java 9, and Java 16 (or just
17, as that's what's widely used in reality).

On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger wrote:

No regressions in our test suite.

Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
daniel.dek...@gmail.com>:

Please test if the next release breaks anything. Then if it looks
right, I will update building instructions, and do other more boring
checks (distro zip contents, etc), and start a release voting.

Change log:

https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html

Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache
*snapshot* Maven repo only:

apache-snapshot-repository
https://repository.apache.org/content/repositories/snapshots/
false
true

(Of course you can also download the jar directly, but be careful to
pick the latest:

https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/
)

--
Best regards,
Daniel Dekany

Re: 2.3.33 pre-vote testing

2024-03-12 Thread Jacques Le Roux


Hi Daniel,

We have started testing with https://issues.apache.org/jira/browse/OFBIZ-12934.

For now we only crossed things to change in OFBiz that makes sense.

We will let you informed in case we cross real issues.

Thanks

Jacques

Le 12/03/2024 à 01:18, Daniel Dekany a écrit :

By the way... if there are bugs, behavior can change with the Java
version, the break points being Java 8, Java 9, and Java 16 (or just
17, as that's what's widely used in reality).

On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger  wrote:

No regressions in our test suite.

Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
daniel.dek...@gmail.com>:


Please test if the next release breaks anything. Then if it looks
right, I will update building instructions, and do other more boring
checks (distro zip contents, etc), and start a release voting.

Change log:

https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html

Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache
*snapshot* Maven repo only:

 
   apache-snapshot-repository
   
https://repository.apache.org/content/repositories/snapshots/
   false
   true
 

(Of course you can also download the jar directly, but be careful to
pick the latest:

https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/
)

--
Best regards,
Daniel Dekany

Re: Dropping support for vintage Servlet and JSP versions with next release?

2023-12-21 Thread Jacques Le Roux


Le 21/12/2023 à 19:02, Daniel Dekany a écrit :

I propose increasing the lowest supported Serlvet/JSP versions to 3.0/2.2,
starting with the next release (FreeMarker 2.3.33). From Tomcat
perspective, that's Tomcat 7 (2011-01-14, EOL since 2021-03-31). This will
simplify the source code and the build a bit, which will also come handy
for generating the Jakarta version.

Currently (2.3.32) the lowest version we support is Serlvet 2.4 and JSP
2.0, and then there's some special support class for JSP 2.1 (that's a
complication we could drop with this). With Tomcat versions: 2.4/2.0 is
Tomcat 5 (2003-12-03), and 2.5/2.1 is 6 (2007-02-2, EOL 2016-12-31). I
think somebody who still uses such ancient servlet containers is unlikely
to care about updating FreeMarker.

Any thoughts?


Hi Daniel,

Your proposition sounds reasonable to me.

Thanks

Jacques

Re: Long-Awaited FreeMarker 3 Preview Available

2023-11-13 Thread Jacques Le Roux

Thanks Jonathan for all the details.

I'll have a deeper look...

Jacques

Le 12/11/2023 à 22:03, Jonathan Revusky a écrit :

On Fri, Nov 10, 2023 at 8:02 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Jonathan,

Salut, Jacques.

What about existing projects using the Apache version ?

Well, what about them? The basic problem is here not very different from
the decision to upgrade to a newer, not 100% backward compatible version of
whatever, like moving from Python 2.x to Python 3.x.

Now, one thing to be clear about is that in its out-of-the-box
configuration, practical NO existing Apache FreeMarker template will work
with the newer version. That's because, by default, directives like
<#assign..> and <#local...> don't work. But if you put <#ftl legacy_syntax>
up top in your template, then they do work.

But anyway, the thing is that there are different levels of user. If you
have a very basic usage pattern, like you just build up some data model
that is a tree of hashes and maps ending in scalars (strings and numbers)
and you expose that data model to your templates... well, the truth of the
matter would surely be that there is very little difference between
FreeMarker 2 and FreeMarker 3. Now, there are massive differences under the
hood and this is now very largely a rewrite, but what I mean is that a user
with a very simplistic usage pattern, (which actually could well be the
majority of users!) just would likely not notice much difference. Though,
again, they would have to use the legacy_syntax configuration or just about
nothing will work!

Since my announcement, I put up a new page which tries to gather together
all the new features in one spot. That is here:
https://github.com/freemarker/freemarker3/wiki/Summary-of-New-Features

I mean the move from 2.3 version to 2.4. Like:

1. Would it be an easy move?

Well, again, this is a very nuanced question because there are different
kinds of users. As I say, if you have a very basic vanilla usage pattern it
probably is an easy move. In fact, most likely your templates will continue
to work with no changes (or close to none) in the legacy_syntax mode, but
even getting them to work without that is probably not so hard.

But, of course, the flip side to that is that, yes, it would probably be
quite easy to upgrade, but if your usage of the thing is that simple, then
there may not be much benefit either! That's true enough.

Now, on the other hand, if you are what is popularly called a "power user",
really pushing the limits in terms of what the tool can do, then I would
say that almost certainly you should try to move to the newer version.
(Even if it will be harder initially.) That is for a variety of reasons. If
you're a power user, and you are hitting limits in what the tool can do,
and you suggest a new feature, well, let's face it. The likelihood of that
new feature being implemented in "Apache FreeMarker" is extremely low. The
version that is now being actively developed is FreeMarker 3, and if
somebody has an idea that seems well motivated it is very likely that I'll
implement it. But the other aspect is that the codebase is so much cleaner
that it is easy now. I don't know what your level of familiarity with the
code is, but you would likely know that the grammar/parser part was written
using this rather old tool called JavaCC. FreeMarker 3 is written using
CongoCC, which is a vastly more advanced version of JavaCC. CongoCC started
as a fork of JavaCC but is now a total rewrite. But, to give you an example
of what I'm talking about, that page I linked mentions various new
features. Let's take the ternary operator as an example. Here is where it
is implemented:
https://github.com/freemarker/freemarker3/blob/master/src/parser/Expressions.inc.ccc#L95
or here, for example, is where the #assert and #exec directives are
implemented:
https://github.com/freemarker/freemarker3/blob/master/src/parser/Directives.inc.ccc#L417-L459

So, the point is that, what with using a much more powerful parser
generator tool, and the codebase being so cleaned up, it is extremely easy
to implement new features, certainly compared to trying to do it against
the 2.3 codebase. So, in particular, for anybody who really aspires to
develop more of a relationship with the code, the FreeMarker 3 codebase is
really where it's at. That's clear enough. Again, I don't know what your
understanding level of the code is, but there were things that were really
a bear to deal with in the legacy codebase, like all this
wrapping/unwrapping of variables. That's all gone. It also means that a lot
of things do actually just work more simply because you're just working
with Java objects, not all this wrapped TemplateXXXModel nonsense. So, when
write:

#var myList = [1, 2, 3]

the object constructed is not some weird wrapper object. It's jus

Re: Long-Awaited FreeMarker 3 Preview Available

2023-11-09 Thread Jacques Le Roux


Hi Jonathan,

What about existing projects using the Apache version ?

I mean the move from 2.3 version to 2.4. Like:

1. Would it be an easy move?
2. What does it brings?
3. What are the pros and cons of each version?
4. etc.

I guess that's not easy questions to answer to (4 being somehow a joke ;), but 
they are fundamental.

TIA

Jacques

Le 10/11/2023 à 02:50, Jonathan Revusky a écrit :

On Thu, Nov 9, 2023 at 9:00 PM Benjamin Marwell  wrote:


I never knew there was an "original" freemarker project.


So you actually thought that FreeMarker was developed at Apache?

Well, no. FreeMarker is a very very old project at this point. FreeMarker 1
was originally written by a guy named Benjamin Geer, in the late 90's.
Though Ben Geer was, strictly speaking, the original author, I don't think
he was really involved in the project for very long. He wasn't involved
when I showed up in the community in late 2001 anyway. At that point, I
basically took over, and within a few months, the thing was a complete
rewrite. And that was when FreeMarker 2.0 came into being. From 2002 to
2004/2005 we went through 4 release cycles, 2.0, 2.1, 2.2, and 2.3. Each
release cycle added quite a bit more functionality. It is kinda sad that
there is just about no meaningful difference between 2023 "Apache
FreeMarker" and FreeMarker 2.3 from 2005 (or even late 2004).

But the thing to understand is that this Apache FreeMarker code, the
continuation of the FreeMarker 2.3 codebase, is really something very
ancient. Most of the work on this was done in the period from 2002 to 2005
or so, about a decade before there was any "Apache FreeMarker". Basically,
the project was very old and stagnant at that point and came to Apache to
die, I guess. So I've decided to resuscitate it. Or give it my best shot...



Your web site is down, the documentation on the GitHub project is sparse.


That is true at the moment but is all quite remediable -- especially if
some people want to get involved and do some heavy lifting. (I get the
feeling that's not you!) In any case, I said quite clearly that this is a
preview. You can't expect something that is a preview to be as polished as
something as old as FreeMarker 2.3, which has been pretty stable since 2004
or thereabouts!



There is no way to tell whether it really is more advanced or not.


Well,  frankly, this is just nonsense. There is no legitimate controversy
over whether this version of FreeMarker is more advanced or not. Of course
it is. As I explained in the previous note in response to Taher Alkhateeb,
it is built on top of the 2.4 codebase, while Apache FreeMarker is a
continuation of the 2.3 codebase. Aside from that, just scan over the
commit record:https://github.com/freemarker/freemarker3/commits/master
Truth told, over the last few months, I have effected something close to a
complete rewrite.

But this is just ridiculous! Tell me, do you think there is some legitimate
controversy over whether JDK 8 is more advanced than JDK 7? That's just
silly. In any case, both FreeMarker 2.3 and this FreeMarker 3.0 preview
that I just announced are largely my work. Is it possible that an earlier
version of work by the same author is more advanced than the later version?
Does that make any sense? Of course this version is more advanced!

It can never be on Maven central, because the namespace (groupid)

"freemarker" is already claimed by Apache Freemarker.


Well, Ben... it is kind of disrespectful to talk such blatant nonsense to
somebody. This is supposed to be some serious technical forum, isn't it?

The "groupid" used on Maven Central is not something with any real
transcendence at all. It certainly has no technical meaning. I mean, look,
here is an example. The main OSS project I'm working on, as I said before,
is CongoCC. A few months ago, our project (finally!) put out an "artifact"
on Maven Central. That is here:
https://central.sonatype.com/artifact/org.congocc/org.congocc.parser.generator
I later realized that somebody else had previously put up a Maven artifact.
That is here:
https://central.sonatype.com/artifact/com.clickhouse/org.congocc  Funny
enough, the guy who put that up was not even in touch with us about it
beforehand. But the one we put up is, I guess, under org.congocc and the
one put up earlier by a third party is under com.clickhouse, which I guess
is the URL he controls or his employer, or... I dunno... Actually, I just
looked, and there is a patched version of FreeMarker 2.3.29 put up by
Liferay, which is this one:
https://central.sonatype.com/artifact/com.liferay/org.freemarker

But the point is that it just doesn't matter! The whole idea that I can't
put something on Maven Central because this nothingburger project controls
the freemarker.org domain... Well, okay, I guess it's true that we can't
use "org.freemarker" as a groupid since it's taken but... so what? So we
use something else. (Duh.) When I decided on CongoCC as a new name for the
parser generator project, I chec

Re: [VOTE] Release Apache FreeMarker 2.3.32

2023-01-07 Thread Jacques Le Roux


Le 06/01/2023 à 20:29, Daniel Dekany a écrit :

The artifacts to be voted upon are located here:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.32/source/
where the source release artifacts are:
- Normal (non-gae) variant:
   apache-freemarker-2.3.32-src.tar.gz
- "gae" variant:
   apache-freemarker-gae-2.3.32-src.tar.gz

See the README.md inside them for build instructions!

Hi Daniel,

Following instruction in the README, in OFBiz trunk build.gradle adding this 
repository

    maven {
    url "https://repository.apache.org/content/repositories/staging/";
    }

and using

    implementation 'org.freemarker:freemarker:2.3.32'

as far as I can tell all seems to go well

+1 binding

Re: Pushing for minimal but quick 2.3.32

2023-01-01 Thread Jacques Le Roux


Hi Daniel,

Our brain is dragging up much energy. I wish you will get enough time to rest, 
heal and have a very good 2023 new year.

Jacques

Le 01/01/2023 à 00:20, Daniel Dekany a écrit :

if my health allows it. I'm quite sick.

Re: [GitHub] [freemarker-docgen] dependabot[bot] opened a new pull request, #2: Bump minimist from 1.2.5 to 1.2.6 in /freemarker-docgen-core

2022-05-21 Thread Jacques Le Roux


Thanks for the info Daniel,

I'll close the PR with a reference to this convo.

Le 21/05/2022 à 10:58, Daniel Dekany a écrit :

It wasn't merged as the file it tries to fix is actually generated.
It's package.json that should be updated, but minimist is only a transitive
dependency there, and I didn't invest into figuring this out, as we aren't
affected by this kind of security issues, as are purely client side with
these, and have no logins, or any user information to steal.

On Wed, Apr 13, 2022 at 7:15 AM GitBox  wrote:


dependabot[bot] opened a new pull request, #2:
URL: https://github.com/apache/freemarker-docgen/pull/2

Bumps [minimist](https://github.com/substack/minimist) from 1.2.5 to
1.2.6.

Commits

https://github.com/substack/minimist/commit/7efb22a518b53b06f5b02a1038a88bd6290c2846";>7efb22a
1.2.6
https://github.com/substack/minimist/commit/ef88b9325f77b5ee643ccfc97e2ebda577e4c4e2";>ef88b93
security notice for additional prototype pollution issue
https://github.com/substack/minimist/commit/c2b981977fa834b223b408cfb860f933c9811e4d";>c2b9819
isConstructorOrProto adapted from PR
https://github.com/substack/minimist/commit/bc8ecee43875261f4f17eb20b1243d3ed15e70eb";>bc8ecee
test from prototype pollution PR
See full diff in https://github.com/substack/minimist/compare/1.2.5...1.2.6";>compare
view





[![Dependabot compatibility score](
https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=minimist&package-manager=npm_and_yarn&previous-version=1.2.5&new-version=1.2.6)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores
)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---


Dependabot commands and options


You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen the
PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen the
PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the PR
or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the
default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as
the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as
the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as
the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the
[Security Alerts page](
https://github.com/apache/freemarker-docgen/network/alerts).




--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@freemarker.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [GitHub] [freemarker-docgen] dependabot[bot] opened a new pull request, #2: Bump minimist from 1.2.5 to 1.2.6 in /freemarker-docgen-core

2022-05-20 Thread Jacques Le Roux


Hi,

Is there a reason why this PR has not been pushed?

TIA

Jacques

Le 13/04/2022 à 07:15, GitBox a écrit :

dependabot[bot] opened a new pull request, #2:
URL: https://github.com/apache/freemarker-docgen/pull/2

Bumps [minimist](https://github.com/substack/minimist) from 1.2.5 to 1.2.6.

Commits

https://github.com/substack/minimist/commit/7efb22a518b53b06f5b02a1038a88bd6290c2846";>7efb22a
 1.2.6
https://github.com/substack/minimist/commit/ef88b9325f77b5ee643ccfc97e2ebda577e4c4e2";>ef88b93
 security notice for additional prototype pollution issue
https://github.com/substack/minimist/commit/c2b981977fa834b223b408cfb860f933c9811e4d";>c2b9819
 isConstructorOrProto adapted from PR
https://github.com/substack/minimist/commit/bc8ecee43875261f4f17eb20b1243d3ed15e70eb";>bc8ecee
 test from prototype pollution PR
See full diff in https://github.com/substack/minimist/compare/1.2.5...1.2.6";>compare view





[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=minimist&package-manager=npm_and_yarn&previous-version=1.2.5&new-version=1.2.6)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)

[//]: # (dependabot-automerge-end)

---



Dependabot commands and options


You can trigger Dependabot actions by commenting on this PR:

- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your 
CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default 
for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the 
default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the 
default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the 
default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/freemarker-docgen/network/alerts).

Re: November board report draft

2021-11-10 Thread Jacques Le Roux


+1

Jacques

Le 10/11/2021 à 11:38, Daniel Dekany a écrit :

Here it is - pretty standard stuff mostly:
https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft+-+November+2021

Any comments? This will be submitted today.

Re: August board report draft

2021-08-11 Thread Jacques Le Roux


Thanks Daniel,

Looks good to me, +1 to submit

Jacques

Le 11/08/2021 à 08:30, Daniel Dekany a écrit :

Hi,

This below is what I plan to submit today. The usual template, without any
additions this time. Any additions from someone?
https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft+-+August+2021

Re: May board repot draft (due today)

2021-05-12 Thread Jacques Le Roux


Sounds good to me too, thanks Daniel!

Le 12/05/2021 à 09:33, Woonsan Ko a écrit :

Looks good to me, too!
Thank you very much!

Woonsan

On Wed, May 12, 2021 at 4:26 PM Jacopo Cappellato
 wrote:

it looks good to me, thank you!

Jacopo

On Wed, May 12, 2021 at 8:09 AM Daniel Dekany  wrote:

Hello,

I have to send the board report today. Anybody has anything to add/change?
https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft+-+May+2021

Re: Suggestion: Discourse Forum for Freemarker?

2021-03-21 Thread Jacques Le Roux




Le 18/03/2021 à 21:55, Christoph Rüger a écrit :

On 2021/03/07 06:48:56, Jacques Le Roux  wrote:
Thanks and sorry for the late reply.

Not sure personally if I like the Slack idea here. Since Slack chat is by nature supposed 
to be more real-time I imagine it makes sense if you have a larger community being 
"always online" and interaction. For freemarker I think a more asynchronous 
medium is better since it is currently more low-traffice. I could be wrong but I imagine 
it a bit more silent chat, and not sure the useful content would be available for the 
public.

The advantage of a forum like Discourse is the asynchronous nature and the 
easier accessibility (public forum = indexed in google). I know the archive 
https://lists.apache.org/list.html?dev@freemarker.apache.org is also index in 
google, butwait a minute speaking of the archive I just realized 
that it is possible to register online in the archive and even reply from 
online directly on the website - what I am doing right now :)

So maybe this serves a similar purpose as I had in mind with discourse forum. 
Discourse is a bit more feature rich with quoting, tagging, etc. but that's not 
too important.

I think I will try it out that way and I am fine :) Forget my initial 
suggestion.
Have a nice evening.


Yes, as we use to say in Apache: "if it's not in the ML it does not exist at 
all". That's what I believe too ;)

Have a good weekend

Jacques

Re: Suggestion: Discourse Forum for Freemarker?

2021-03-06 Thread Jacques Le Roux


Le 24/02/2021 à 15:57, Christoph Rüger a écrit :

Hi all,

I just wanted to ask, what you think about having a Discourse Forum for
Freemarker. They are offering a free version for OSS projects.
https://blog.discourse.org/2018/11/free-hosting-for-open-source-v2/

I just saw it in another Open Source project I am participating (bndtools
): They now have a Discourse Forum which
replaced their Google groups Mailinglist. Since then I think

I personally like discourse forums a lot and I think they have good tools
for improved discussions (tagging, quotes, pasting screenshots). I think it
makes the community more visible and encourages interaction.
Not sure what the policy is about that since Freemarker is an Apache
project.

Just wanted to bring this up for discussion.

Christoph


Hi Christoph,

We could rather create a #freemarker channel at the ASF. Like for instance we 
have https://the-asf.slack.com/archives/CD3TJJJ5B

Jacques

Re: [VOTE] Release Apache FreeMarker 2.3.31

2021-02-13 Thread Jacques Le Roux


+1 (binding)

Tested in OFBiz trunk HEAD, UI and console OK. I even spotted an old small 
issue in log that did not show before :)

Jacques

Le 13/02/2021 à 12:31, Siegfried Goeschl a écrit :

+1 (non-binding)

Tested with freemarker-generator

Thanks in advance,

Siegfried Goeschl



On 12.02.2021, at 20:12, Christoph Rüger  wrote:

+1 (non-binding)

Verified running our testsuite containing some FM related tests
with org.freemarker.freemarker-2.3.31.jar .
no regression found, all testcases successful.

Regards
Christoph

Am Mi., 10. Feb. 2021 um 23:51 Uhr schrieb Woonsan Ko :


+1 (binding)

Verified the following:
- gpg --verify with the .asc files: OK
- sha512 checksums: OK
- builds and artifacts in both "normal" and "gae": OK
  (ant, ant test, ant javadoc, ant manualOffline, ant maven-install)
- testing in a CMS product with the freemarker-2.3.31.jar: OK

Regards,

Woonsan


On Tue, Feb 9, 2021 at 5:20 PM Daniel Dekany  wrote:

Hi all,

Please vote on releasing FreeMarker 2.3.31!

As there were changes in the last few days, don't skip testing with
your dependent projects, even if you already did it recently.

Release Notes:
https://freemarker.apache.org/builds/2.3.31-voting/versions_2_3_31.html

Before proceed, you should know that FreeMarker 2.3.x, for a long
time, always releases a normal and a "gae" variant on the same time,
which are technically two independent source trees (Git branches). The
"gae" variant contains a few small modification in the Java source
code to be Google App Engine compliant, and has freemarker-gae as the
Maven artifact name. Otherwise the normal and the "gae" branches are
identical. Hence they will be voted on together.

The commits to be voted upon are:
- Normal (non-gae) variant:



https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=f2308d4b4c242901e6a0e71cb12082243479f69c

  Commit hash: f2308d4b4c242901e6a0e71cb12082243479f69c
- "gae" variant:



https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=8d15d85c70df172e5c8ad64f6ba05d52dcac663c

  Commit hash: 8d15d85c70df172e5c8ad64f6ba05d52dcac663c

The artifacts to be voted upon are located here:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.31/source/
where the source release artifacts are:
- Normal (non-gae) variant:
  apache-freemarker-2.3.31-src.tar.gz
- "gae" variant:
  apache-freemarker-gae-2.3.31-src.tar.gz

See the README.md inside them for build instructions!

The release artifacts are signed with the following key:
https://people.apache.org/keys/committer/ddekany.asc

For convenience, we also provide binaries, which also need to be checked:


https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.31/binaries/

and Maven artifacts in the ASF Staging Repository:


https://repository.apache.org/content/repositories/staging/org/freemarker/freemarker/2.3.31/

Please try out the package and vote!

The vote is open for a minimum of 72 hours or until the necessary number

of

votes (3 binding +1s) is reached.

[ ] +1 Release this package as Apache FreeMarker 2.3.31
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...

Please add "(binding)" if your vote is binding.

--
Thanks,
Daniel Dekany

--
Synesty GmbH
Moritz-von-Rohr-Str. 1a
07745 Jena
Tel.: +49 3641
5596493Internet: https://synesty.com 
Informationen
zum Datenschutz: https://synesty.com/datenschutz


Geschäftsführer: Christoph Rüger
Unternehmenssitz: Jena
Handelsregister B beim Amtsgericht: Jena
Handelsregister-Nummer: HRB 508766
Ust-IdNr.: DE287564982

Re: Board report draft for November 11

2020-11-11 Thread Jacques Le Roux


+1

Jacques

Le 11/11/2020 à 14:21, Woonsan Ko a écrit :

Hi Daniel,

Looks good! Thank you so much!

Kind regards,

Woonsan

On Tue, Nov 10, 2020 at 2:50 PM Daniel Dekany  wrote:

Hi,

At least if you are in the PMC, please check below draft, and recommend
anything that comes into mind:

https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft+-+November+2020

Thanks!

--
Best regards,
Daniel Dekany

Re: FreeMarker generator security related configuration defaults

2020-10-18 Thread Jacques Le Roux


OK, no problem with me

Le 17/10/2020 à 20:48, Daniel Dekany a écrit :

What I'm saying is that we should enable those unsafe features, as this
command line tool is "unsafe" anyway. I quoted unsafe, because a command
line tool like this is not something that sane developer would expose to
untrusted users. (It's like saying rm is unsafe... yeah, it has to be,
something needs to be able to delete stuff.)

On Sat, Oct 17, 2020 at 8:32 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Daniel,

Indeed, these possible security issues are not obvious to everyone.
Disabling unsafe features is indeed a convenient way to make them prominent.

Jacques

Le 11/10/2020 à 20:42, Daniel Dekany a écrit :

I noticed that ?api and ?new are by default disabled in
freemarker-generator. However, freemarker-generator is inherently unsafe,
as it has tools.freemarker.objectConstructor, and

tools.freemarker.statics.

For a command-line tool that's probably fine, but then above two
configuration settings should be left on their convenient defaults as

well.

In general, allowing someone to specify arbitrary command line arguments
to freemarker-generator CLI means that they can do pretty much anything

(as

they can provide an arbitrary template with the -i option, then access

the

tools). Again, I think such risk is expected from a command line tool,

but

it's better if we are conscious about this.

Re: FreeMarker generator security related configuration defaults

2020-10-17 Thread Jacques Le Roux


Thanks Daniel,

Indeed, these possible security issues are not obvious to everyone. Disabling 
unsafe features is indeed a convenient way to make them prominent.

Jacques

Le 11/10/2020 à 20:42, Daniel Dekany a écrit :

I noticed that ?api and ?new are by default disabled in
freemarker-generator. However, freemarker-generator is inherently unsafe,
as it has tools.freemarker.objectConstructor, and tools.freemarker.statics.
For a command-line tool that's probably fine, but then above two
configuration settings should be left on their convenient defaults as well.

In general, allowing someone to specify arbitrary command line arguments
to freemarker-generator CLI means that they can do pretty much anything (as
they can provide an arbitrary template with the -i option, then access the
tools). Again, I think such risk is expected from a command line tool, but
it's better if we are conscious about this.

Re: August 2020 Board report draft

2020-08-12 Thread Jacques Le Roux


+1

Jacques

Le 11/08/2020 à 19:25, Daniel Dekany a écrit :

Please find the board report draft here (will be submitted tomorrow), and
comment if anything is missing or incorrect:
https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft+-+August+2020

Thanks!

Re: "freemarker-cli" command should be renamed to "freemarker-generator"

2020-08-04 Thread Jacques Le Roux


+1 for freemarker-generator name

Jacques

Le 04/08/2020 à 02:24, Daniel Dekany a écrit :

I brought this up earlier (can't find the mail), and it was not concluded.
The "product" name is freemarker-generator, therefore the command line
command (script) name should be freemarker-generator too, and not
freemarker-cli.  Can we agree on this, and go ahead and rename those
executables? Then I will do the same in the Docgen documentation. If
there's a disagreement... read on.

If users keep typing freemarker-cli, they will start calling the product
"FreeMarker CLI", which is confusing, as we call it "FreeMarker Generator",
like when doing a release, or any communication, other than showing an
example command line call.  Besides, it's just the convention that if a
product has a CLI, like let's say Java has one, the main CLI is just called
the product name ("java" in this case), but certainly not
${productName}-cli. Because usually it's obvious for the user that they
calls a CLI, when it's done. (Anyway, the product name is not just
"freemarker", which is the template engine.)

Re: FreeMarker generator release preparations

2020-07-26 Thread Jacques Le Roux


Great, thanks to both!

Jacques

Le 26/07/2020 à 12:30, Siegfried Goeschl a écrit :

Hi Daniel,

I‘m currently somewhere in the Austrian mountains and should be back on Tuesday 
evening the latest.

• Had a quick read and things look good
• Will get my hands dirty on Maven thing
• Could we create a ticket & feature branch to keep track of the changes?

Thanks in advance

Siegfried Goeschl


Am 26.07.2020 um 12:17 schrieb Daniel Dekany :

I didn't really expect anyone to help me in this case. On the contrary, I'm
trying to help in this process.

Siegfried, do you disagree with some of the above points? Do you want to
tackle some of them yourself? As time allows, I can do them, but of course
we shouldn't step on each other's toes.


On Sun, Jul 26, 2020 at 11:00 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Daniel,

I may help, though it seems you already done most of it. What help would
you expect now?

Thanks for all the good work!

Jacques


Le 26/07/2020 à 01:27, Daniel Dekany a écrit :
I said I will help in the Apache release process, so only focusing on

that,

so some points:

- We are required to have a so-called source release (every other
artifact is optional in the policy). As we are using the

org.apache:apache

parent, that should generate that automatically, with .asc and

sha512 and

all. But currently it doesn't, because maven-release-plugin

config/argument

is overwritten with this:

-Dmaven.javadoc.skip=true.

We should keep configuring release at minimum, to avoid such

accidents.

Maybe as in
https://github.com/apache/freemarker-docgen/blob/master/pom.xml#L70.
- I assume we also want a binary release, for the CLI only, and
freemarker-generator-cli-x.y.z-*app*.zip (note the "-app") will be

our

binary release artifact. Then:
- It bundles some dependency binaries that are not under ASL2

license.

   Unfortunately, the licenses of those must be included in the
distribution.
   See the LICENSE at
   https://github.com/apache/freemarker-docgen/blob/master/LICENSE.

At

   the bottom, it lists the licenses, then it refers to the actual

license

   files. As we will have many licenses, let's create a "licenses"

directory

   for them. (In the future, the dependencies have to be checked
for changes.
   Even version upgrades my pull in sneaky transient dependencies.

Some

   licenses are not even allowed, so anything but ASL2, MIT,
   BSD-without-advertisement-clause, will need closer attention.)
   - I noticed that the documentation is not included in the binary
   distribution. But because of the extra legal burden including it

would

   bring (we have fonts and icons under CC-SA and SIL OFL in the

Docgen

   output), I actually prefer that to stay like that.
   - .sha512 file is not yet generated
- freemarker-generator-cli/src/site: If you agree, instead of this I
will create freemarker-generator*-site*/src/docgen, and convert the
Markdown to XDocBook. For now this will be only the CLI

documentation, and

the JavaDoc, as the freemarker-generator-maven-plugin is not ready.

One

annoyance I realized is that we should have Docgen in Maven Central

for the

builds to work reliably in the future, which means that Docgen has

to be

officially released (it never was, it's an internal tool). That

would be a

minimalistic release, means, no announcement, no web site, just the

bare

minimum (i.e., source release, and deployment to Maven Central). I

have

some backlog there (Google keeps nagging me about mobile issues),

but I

hope I can fix that in the coming days, then go through the official
release process (takes 1-2 weeks).
- Some smaller things:
   -
   - Having a "release" profile is also hopefully unnecessary,

because

   org.apache:apache takes care of signing.
   - We should also remove most plugin version management, as many of
   those versions are set in org.apache:apache.
   - freemarker-generator-cli/templates should be inside
   freemarker-generator-cli/src/main/templates, I guess.

P.s.: Siegfired asked our opinions in another thread. I did my part, even
too much (;, so, would be good if others participate in that as well.



--
Best regards,
Daniel Dekany

Re: FreeMarker generator release preparations

2020-07-26 Thread Jacques Le Roux


Hi Daniel,

I may help, though it seems you already done most of it. What help would you 
expect now?

Thanks for all the good work!

Jacques

Le 26/07/2020 à 01:27, Daniel Dekany a écrit :

I said I will help in the Apache release process, so only focusing on that,
so some points:

- We are required to have a so-called source release (every other
artifact is optional in the policy). As we are using the org.apache:apache
parent, that should generate that automatically, with .asc and sha512 and
all. But currently it doesn't, because maven-release-plugin config/argument
is overwritten with this: -Dmaven.javadoc.skip=true.
We should keep configuring release at minimum, to avoid such accidents.
Maybe as in
https://github.com/apache/freemarker-docgen/blob/master/pom.xml#L70.
- I assume we also want a binary release, for the CLI only, and
freemarker-generator-cli-x.y.z-*app*.zip (note the "-app") will be our
binary release artifact. Then:
- It bundles some dependency binaries that are not under ASL2 license.
   Unfortunately, the licenses of those must be included in the
distribution.
   See the LICENSE at
   https://github.com/apache/freemarker-docgen/blob/master/LICENSE. At
   the bottom, it lists the licenses, then it refers to the actual license
   files. As we will have many licenses, let's create a "licenses" directory
   for them. (In the future, the dependencies have to be checked
for changes.
   Even version upgrades my pull in sneaky transient dependencies. Some
   licenses are not even allowed, so anything but ASL2, MIT,
   BSD-without-advertisement-clause, will need closer attention.)
   - I noticed that the documentation is not included in the binary
   distribution. But because of the extra legal burden including it would
   bring (we have fonts and icons under CC-SA and SIL OFL in the Docgen
   output), I actually prefer that to stay like that.
   - .sha512 file is not yet generated
- freemarker-generator-cli/src/site: If you agree, instead of this I
will create freemarker-generator*-site*/src/docgen, and convert the
Markdown to XDocBook. For now this will be only the CLI documentation, and
the JavaDoc, as the freemarker-generator-maven-plugin is not ready. One
annoyance I realized is that we should have Docgen in Maven Central for the
builds to work reliably in the future, which means that Docgen has to be
officially released (it never was, it's an internal tool). That would be a
minimalistic release, means, no announcement, no web site, just the bare
minimum (i.e., source release, and deployment to Maven Central). I have
some backlog there (Google keeps nagging me about mobile issues), but I
hope I can fix that in the coming days, then go through the official
release process (takes 1-2 weeks).
- Some smaller things:
   -
   - Having a "release" profile is also hopefully unnecessary, because
   org.apache:apache takes care of signing.
   - We should also remove most plugin version management, as many of
   those versions are set in org.apache:apache.
   - freemarker-generator-cli/templates should be inside
   freemarker-generator-cli/src/main/templates, I guess.

P.s.: Siegfired asked our opinions in another thread. I did my part, even
too much (;, so, would be good if others participate in that as well.

Re: Use TemplateClassResolver.SAFER_RESOLVER by default

2020-05-17 Thread Jacques Le Roux

Thanks Daniel,

Especially, about the link you provided. I'll double check that!

Jacques

Le 17/05/2020 à 11:08, Daniel Dekany a écrit :

It's not backward compatible to change it, but if it would be really useful
to use SAFER_RESOLVER, then we should do it with incompatible_improvements
anyway (and actually it's scheduled to be done with
incompatible_improvements 2.4). However, it's not too useful as far as I
see. If you trust people who write the templates, and so accept that
security wise they have the same power as Java developers, then the
non-restrictive default is not a big deal. If you don't trust them, then
all these light protections are basically useless, and you need to
white-list class members anyway, including the constructors that you want
to be accessible through ?new. I'm not sure if there's an in-between
solution that's good for anything, since you defense is only as strong as
it's weakest point. See also:
https://freemarker.apache.org/docs/app_faq.html#faq_template_uploading_security

Then the question arises, why do we have SAFER_RESOLVER, and for that
mater, the default blacklisting of some methods (often referred to as the
"unsafe methods") at all? If you ask me now, maybe we shouldn't have those.
When FreeMarker was made, untrusted template weren't considered at all
(apparently). The mindset was to provide an alternative to JSP (the old
one, that didn't even have ${...} yet), and the goal of the separation of
Java code and templates was the separation of the presentation aspect, to
support MVC pattern better. In JSP, back then, having Java code snippets
was the norm, so that wasn't about security either. But as it turns out,
users sometimes think that because you can't enter Java code into templates
(but you can call Java API-s, so it's almost the same), it's somehow a
security barrier as well. As of SAFER_RESOLVER, as far as I remember, some
users were concerned about template authors being able to run arbitrary
commands (cat \etc\passwd, rm -r /stuff, etc.). Again, just like your Java
code can. None the less, make that so easy looked silly for sure. So, I
added SAFER_RESOLVER. So that it takes more will and skill for a template
author to hurt you. Same with blocking attacks published in some blog
entries. But again, if you didn't do all the things in
https://freemarker.apache.org/docs/app_faq.html#faq_template_uploading_security,
then a template author with some persistence and skill will manage to
breach you anyway.

On Sun, May 17, 2020 at 8:41 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,

After reading
https://ackcent.com/blog/in-depth-freemarker-template-injection/ I wonder
why we have not TemplateClassResolver.SAFER_RESOLVER[1] used
by default, like there is:

The api_builtin_enabled configuration setting must be set to true.
Its default is false (at least as of 2.3.22) for not lowering the security
of
existing applications.[2]

Is there a reason?

Thanks

Jacques

[1]
https://freemarker.apache.org/docs/api/freemarker/core/TemplateClassResolver.html#SAFER_RESOLVER
[2]
https://freemarker.apache.org/docs/ref_builtins_expert.html#ref_buitin_api_and_has_api

Use TemplateClassResolver.SAFER_RESOLVER by default

2020-05-16 Thread Jacques Le Roux


Hi,

After reading https://ackcent.com/blog/in-depth-freemarker-template-injection/ I wonder why we have not TemplateClassResolver.SAFER_RESOLVER[1] used 
by default, like there is:


    The api_builtin_enabled configuration setting must be set to true. Its default is false (at least as of 2.3.22) for not lowering the security of 
existing applications.[2]


Is there a reason?

Thanks

Jacques

[1] 
https://freemarker.apache.org/docs/api/freemarker/core/TemplateClassResolver.html#SAFER_RESOLVER
[2] 
https://freemarker.apache.org/docs/ref_builtins_expert.html#ref_buitin_api_and_has_api

Re: Please review May board report draft

2020-05-08 Thread Jacques Le Roux


+1

Jacques

Le 08/05/2020 à 20:13, Daniel Dekany a écrit :

Here it is:
https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft+-+May+2020

Re: [VOTE] Release Apache FreeMarker 2.3.30

2020-02-29 Thread Jacques Le Roux


+1 (binding)

Works for me in UI and with integration tests

Jacques

Le 28/02/2020 à 23:53, David E Jones a écrit :

Sorry for the delay, finally tested the binary release preview build with
the main test suite I have available in Moqui. Looks good.

+1 (binding)

-David


On Wed, Feb 26, 2020 at 10:58 AM Daniel Dekany 
wrote:


Thanks for the votes so far! Anybody else plans to test the release?

On Fri, Feb 21, 2020 at 4:55 AM Woonsan Ko  wrote:


+1 (binding)

Build and tests are okay.

Thanks!

Regards,

Woonsan

On Sun, Feb 16, 2020 at 2:50 PM Daniel Dekany 

wrote:

Hi all,

Please vote on releasing FreeMarker 2.3.30!

As there were changes in the last few days, don't skip testing with
your dependent projects, even if you already did it recently.

Release Notes:


https://freemarker.apache.org/builds/2.3.30-voting/versions_2_3_30.html

Before proceed, you should know that FreeMarker 2.3.x, for a long
time, always releases a normal and a "gae" variant on the same time,
which are technically two independent source trees (Git branches). The
"gae" variant contains a few small modification in the Java source
code to be Google App Engine compliant, and has freemarker-gae as the
Maven artifact name. Otherwise the normal and the "gae" branches are
identical. Hence they will be voted on together.

The commits to be voted upon are:
- Normal (non-gae) variant:



https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=2c481cdbabf3ff96d095d7509532f8b2bebd1a25

   Commit hash: 2c481cdbabf3ff96d095d7509532f8b2bebd1a25
- "gae" variant:



https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=196d28d8482445bff0f2272d388c2b717d454361

   Commit hash: 196d28d8482445bff0f2272d388c2b717d454361

The artifacts to be voted upon are located here:


https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.30/source/

where the source release artifacts are:
- Normal (non-gae) variant:
   apache-freemarker-2.3.30-src.tar.gz
- "gae" variant:
   apache-freemarker-gae-2.3.30-src.tar.gz

See the README.md inside them for build instructions!

The release artifacts are signed with the following key:
https://people.apache.org/keys/committer/ddekany.asc

For convenience, we also provide binaries, which also need to be

checked:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.30/binaries/

and Maven artifacts in the ASF Staging Repository:


https://repository.apache.org/content/repositories/staging/org/freemarker/freemarker/2.3.30/

Please try out the package and vote!

The vote is open for a minimum of 72 hours or until the necessary

number

of

votes (3 binding +1s) is reached.

[ ] +1 Release this package as Apache FreeMarker 2.3.30
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...

Please add "(binding)" if your vote is binding.

--
Thanks,
  Daniel Dekany


--
Best regards,
Daniel Dekany

Re: new committer: Siegfried Goeschl

2020-01-07 Thread Jacques Le Roux


Welcome Siegfried

Jacques

Le 07/01/2020 à 20:22, Woonsan Ko a écrit :

Welcome aboard, Siegfried!

Cheers,

Woonsan

On Tue, Jan 7, 2020 at 1:52 PM Daniel Dekany  wrote:

The Project Management Committee (PMC) for Apache FreeMarker
has invited Siegfried Goeschl to become a committer, and we are
pleased  to announce that he has accepted.

Siegfried Goeschl was around our community for a good while, sometimes
participating on the mailing list, sometimes sharing his FreeMarker related
projects and knowledge elsewhere. He has also expressed interest in
continuing
his project, freemarker-cli, here, as part of the FreeMarker project. He is
also
committer or PMC member in some others Apache projects.

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: JBoss Tools FreeMarker Eclipse plugin fork

2019-08-24 Thread Jacques Le Roux


Thanks a lot for this effort Daniel, Jacques

Le 23/08/2019 à 22:10, Daniel Dekany a écrit :

The most complete Eclipse plugin is still the one that was developed
at JBoss Tools long ago, but it was discontinued 2 years ago. So, I
have taken over basic maintenance in my Github fork
(https://github.com/ddekany/jbosstools-freemarker), and published a
new version on Eclipse Marketplace
(https://marketplace.eclipse.org/content/freemarker-ide). Also, if you
try to open an .ftl, .ftlh or .ftlx file in Eclipse, now Marketplace
will find this plugin automatically.

Basic maintenance practically means replacing the embedded
freemarker.jar with the latest version, and uploading to Bintray, and
adding a new version on Eclipse Marketplace. Anyone, especially any
PMC member with Bintray and Eclipse user, to who I can give right to
editing these? Just so that releasing a new plugin version stays
possible even if I'm not available.

The biggest problem with this plugin is that it only recognizes FTL
syntax, not the static text. Like in a HTML template you have no HTML
syntax highlighting/completion. This limits the use cases. To address
that, there's https://github.com/angelozerr/lsp4e-freemarker, but it
has become inactive. Would be great if someone picks that up.

Re: [VOTE] Release Apache FreeMarker 2.3.29

2019-08-17 Thread Jacques Le Roux


+1 (binding)

Using temporarily (more for my own reminder)

Index: build.gradle
===
--- build.gradle(revision 1865342)
+++ build.gradle(working copy)
@@ -131,6 +131,9 @@
 repositories{
 jcenter()
 mavenLocal()
+  maven {
+  url 'https://repository.apache.org/content/repositories/staging'
+}
 }
 }
 
@@ -199,7 +202,7 @@

 implementation 'org.apache.xmlrpc:xmlrpc-client:3.1.3'
 implementation 'org.apache.xmlrpc:xmlrpc-server:3.1.3'
 implementation 'org.codehaus.groovy:groovy-all:2.4.16' // Remember to 
change the version number in javadoc.options block
-implementation 'org.freemarker:freemarker:2.3.28' // Remember to change 
the version number in FreeMarkerWorker class when upgrading
+implementation 'org.freemarker:freemarker:2.3.29' // Remember to change 
the version number in FreeMarkerWorker class when upgrading
 implementation 'org.owasp.esapi:esapi:2.2.0.0'
 implementation 'org.springframework:spring-test:5.1.9.RELEASE'
 implementation 'org.zapodot:jackson-databind-java-optional:2.6.1'
 
OFBiz tests pass and OFBiz seems to run w/o problems


Jacques

Le 10/08/2019 à 00:54, Daniel Dekany a écrit :

Hi all,

Please vote on releasing FreeMarker 2.3.29!

As there were changes in the last few days, don't skip testing with
your dependent
projects, even if you already did it recently.

Release Notes:
https://freemarker.apache.org/builds/2.3.29-voting/versions_2_3_29.html

Before proceed, you should know that FreeMarker 2.3.x, for a long
time, always releases a normal and a "gae" variant on the same time,
which are technically two independent source trees (Git branches). The
"gae" variant contains a few small modification in the Java source
code to be Google App Engine compliant, and has freemarker-gae as the
Maven artifact name. Otherwise the normal and the "gae" branches are
identical. Hence they will be voted on together.

The commits to be voted upon are:
- Normal (non-gae) variant:
   
https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=f70ac39487a7f0dc3ab693d36b9798ebf4456c7f
   Commit hash: f70ac39487a7f0dc3ab693d36b9798ebf4456c7f
- "gae" variant:
   
https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=f87eb85972c331a5ca1ff065e8865cb984d769bb
   Commit hash: f87eb85972c331a5ca1ff065e8865cb984d769bb

The artifacts to be voted upon are located here:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.29/source/
where the source release artifacts are:
- Normal (non-gae) variant:
   apache-freemarker-2.3.29-src.tar.gz
- "gae" variant:
   apache-freemarker-gae-2.3.29-src.tar.gz

See the README.md inside them for build instructions!

The release artifacts are signed with the following key:
https://people.apache.org/keys/committer/ddekany.asc

For convenience, we also provide binaries, which also need to be checked:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.29/binaries/
and Maven artifacts in the ASF Staging Repository:
https://repository.apache.org/content/repositories/staging/org/freemarker/freemarker/2.3.29/

Please try out the package and vote!

The vote is open for a minimum of 72 hours or until the necessary number of
votes (3 binding +1s) is reached.

[ ] +1 Release this package as Apache FreeMarker 2.3.29
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...

Please add "(binding)" if your vote is binding.

Re: [VOTE] Release Apache FreeMarker 2.3.29

2019-08-17 Thread Jacques Le Roux


Hi Daniel,

Doing so...

Jacques

Le 16/08/2019 à 09:37, Daniel Dekany a écrit :

Thank you for the votes so far! With my vote we will have the required 3
PMC votes, so no problem there, but if anyone else intends to test the
release, please indicate it. Like, if OFBiz test suite tests lot of
templates, that's maybe a useful to try.

On Sat, Aug 10, 2019 at 12:54 AM Daniel Dekany  wrote:


Hi all,

Please vote on releasing FreeMarker 2.3.29!

As there were changes in the last few days, don't skip testing with
your dependent
projects, even if you already did it recently.

Release Notes:
https://freemarker.apache.org/builds/2.3.29-voting/versions_2_3_29.html

Before proceed, you should know that FreeMarker 2.3.x, for a long
time, always releases a normal and a "gae" variant on the same time,
which are technically two independent source trees (Git branches). The
"gae" variant contains a few small modification in the Java source
code to be Google App Engine compliant, and has freemarker-gae as the
Maven artifact name. Otherwise the normal and the "gae" branches are
identical. Hence they will be voted on together.

The commits to be voted upon are:
- Normal (non-gae) variant:

https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=f70ac39487a7f0dc3ab693d36b9798ebf4456c7f
   Commit hash: f70ac39487a7f0dc3ab693d36b9798ebf4456c7f
- "gae" variant:

https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=f87eb85972c331a5ca1ff065e8865cb984d769bb
   Commit hash: f87eb85972c331a5ca1ff065e8865cb984d769bb

The artifacts to be voted upon are located here:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.29/source/
where the source release artifacts are:
- Normal (non-gae) variant:
   apache-freemarker-2.3.29-src.tar.gz
- "gae" variant:
   apache-freemarker-gae-2.3.29-src.tar.gz

See the README.md inside them for build instructions!

The release artifacts are signed with the following key:
https://people.apache.org/keys/committer/ddekany.asc

For convenience, we also provide binaries, which also need to be checked:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.29/binaries/
and Maven artifacts in the ASF Staging Repository:

https://repository.apache.org/content/repositories/staging/org/freemarker/freemarker/2.3.29/

Please try out the package and vote!

The vote is open for a minimum of 72 hours or until the necessary number of
votes (3 binding +1s) is reached.

[ ] +1 Release this package as Apache FreeMarker 2.3.29
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...

Please add "(binding)" if your vote is binding.

--
Thanks,
  Daniel Dekany

Re: FM3: Increasing minimum Java version to 8

2019-08-05 Thread Jacques Le Roux


+1

Jacques

Le 05/08/2019 à 08:43, Christoph Rüger a écrit :

+1

Am So., 4. Aug. 2019 um 23:51 Uhr schrieb Woonsan Ko :


+1

Woonsan

On Sun, Aug 4, 2019 at 4:04 PM Daniel Dekany  wrote:

I would like to increase the minimum Java version in the FreeMarker *3*
branch to 8, because by the time it will be released, I assume it won't

be

a problem on Android anymore (I guess it's not a problem anymore nowadays
either). This simplifies module structure and packaging.

Re: Board report draft for May 2019

2019-05-09 Thread Jacques Le Roux


+1

Jacques

Le 09/05/2019 à 12:26, Jacopo Cappellato a écrit :

Hi all,

please review the draft of the report that is now due:

https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft+-+May+2019

If there are no objections I am going to submit it today.

Thanks,

Jacopo

Re: Opinions about the new ?truncate built-in?

2019-03-06 Thread Jacques Le Roux


Thanks Daniel,

It will be delayed but I should test it this week

Jacques

Le 06/03/2019 à 08:52, Daniel Dekany a écrit :

Sorry for the later reply...

I have uploaded the current development version (so now it includes
the lambda feature as well) to the Maven snapshot repository:
https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.29-SNAPSHOT/
https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker-gae/2.3.29-SNAPSHOT/

So, ensure that you have the
https://repository.apache.org/content/repositories/snapshots/
repository added to either the project pom.xml (maybe it's already
there for OFBiz - I think it should be anyway), or to
~/.m2/settings.xml as snapshot repository:

Version number is: 2.3.29-SNAPSHOT

Woonsan: This is easier for someone who isn't already set up to build
FreeMarker. See also:
https://freemarker.apache.org/committer-howto.html#deploy-snapshot


Saturday, March 2, 2019, 12:13:09 PM, Jacques Le Roux wrote:


Hi Daniel,

I tried to test this morning using OFBiz, but I have not much time
and freemarker:2.3.29 is not available in Maven (we use Jcenter in our Gradle
build, but I have a local m2 repository too)

https://maven-repository.com/artifact/org.freemarker/freemarker

So I'll wait its release to test except if you can explain me how
to circumvent this issue using my local m2 repository too

Thanks

Jacques

Le 17/01/2019 à 20:13, Daniel Dekany a écrit :

I have added the str?truncate(maxLength) built-in (and its other
variations) to the 2.3-gae head. This is something that users have
requested and implemented their own for who knows how many times, yet
it wasn't added to FreeMarker till now, as there's no single correct
way of text truncation. So what I did is making the algorithm
pluggable, and giving a default that I think reflects a good practice.
I guess most users will just go along (instead of quickly adding some
simplistic #function their own), but those who have other ideas can
still keep using ?truncate.

Please tell your opinions, ideas, or even better, test it!

>From https://freemarker.apache.org/builds/fm2/versions_2_3_29.html:
Added new built-ins for truncating text. string?truncate(length)
truncates the text to the given length, and by default adds [...] at
the end if truncation has happened. Truncation happens at word
boundaries, unless the result is too short that way, in which case it
falls back to truncation mid word. There's also ?truncate_w to force
Word Boundary truncation, and ?truncate_c (for Character Boundary)
that doesn't care about word boundaries. The truncation algorithm is
pluggable in the FreeMarker configuration. See the reference for more
details.

Built-in documentation:
https://freemarker.apache.org/builds/fm2/ref_builtins_string.html#ref_builtin_truncate

Related API-s:
https://freemarker.apache.org/builds/fm2/api/freemarker/core/TruncateBuiltinAlgorithm.html
https://freemarker.apache.org/builds/fm2/api/freemarker/core/DefaultTruncateBuiltinAlgorithm.html
https://freemarker.apache.org/builds/fm2/api/freemarker/core/Configurable.html#setTruncateBuiltinAlgorithm-freemarker.core.TruncateBuiltinAlgorithm-

Commit:
https://github.com/apache/freemarker/commit/7c5ef10ef3da3b94fc5cdf9d61c966282b6cd8ac

Re: Opinions about the new ?truncate built-in?

2019-03-04 Thread Jacques Le Roux

Thanks Woonsan,

I'll do that :)

Jacques

Le 04/03/2019 à 06:20, Woonsan Ko a écrit :

On Sat, Mar 2, 2019 at 6:15 AM Jacques Le Roux
wrote:

Hi Daniel,

I tried to test this morning using OFBiz, but I have not much time and
freemarker:2.3.29 is not available in Maven (we use Jcenter in our Gradle
build, but I have a local m2 repository too)

https://maven-repository.com/artifact/org.freemarker/freemarker

So I'll wait its release to test except if you can explain me how to circumvent
this issue using my local m2 repository too

For another feature (lambda), I tested the feature with a local maven install:

1. Pull and check out 2.3 branch. (I had to use 2.3-gae branch for
lambda feature, but the feature in this thread was also in 2.3
branch.)
2. Build with `ant jar maven-install` (which will build and install
the jar into your local maven repo.)
3. Change the FreeMarker dependency version in your project to 2.3.29-SNAPHSOT.
4. Build/run/test your project.

Regards,

Woonsan

Thanks

Jacques

Le 17/01/2019 à 20:13, Daniel Dekany a écrit :

I have added the str?truncate(maxLength) built-in (and its other
variations) to the 2.3-gae head. This is something that users have
requested and implemented their own for who knows how many times, yet
it wasn't added to FreeMarker till now, as there's no single correct
way of text truncation. So what I did is making the algorithm
pluggable, and giving a default that I think reflects a good practice.
I guess most users will just go along (instead of quickly adding some
simplistic #function their own), but those who have other ideas can
still keep using ?truncate.

Please tell your opinions, ideas, or even better, test it!

>From https://freemarker.apache.org/builds/fm2/versions_2_3_29.html:
Added new built-ins for truncating text. string?truncate(length)
truncates the text to the given length, and by default adds [...] at
the end if truncation has happened. Truncation happens at word
boundaries, unless the result is too short that way, in which case it
falls back to truncation mid word. There's also ?truncate_w to force
Word Boundary truncation, and ?truncate_c (for Character Boundary)
that doesn't care about word boundaries. The truncation algorithm is
pluggable in the FreeMarker configuration. See the reference for more
details.

Built-in documentation:
https://freemarker.apache.org/builds/fm2/ref_builtins_string.html#ref_builtin_truncate

Related API-s:
https://freemarker.apache.org/builds/fm2/api/freemarker/core/TruncateBuiltinAlgorithm.html
https://freemarker.apache.org/builds/fm2/api/freemarker/core/DefaultTruncateBuiltinAlgorithm.html
https://freemarker.apache.org/builds/fm2/api/freemarker/core/Configurable.html#setTruncateBuiltinAlgorithm-freemarker.core.TruncateBuiltinAlgorithm-

Commit:
https://github.com/apache/freemarker/commit/7c5ef10ef3da3b94fc5cdf9d61c966282b6cd8ac

Re: Opinions about the new ?truncate built-in?

2019-03-02 Thread Jacques Le Roux


Hi Daniel,

I tried to test this morning using OFBiz, but I have not much time and freemarker:2.3.29 is not available in Maven (we use Jcenter in our Gradle 
build, but I have a local m2 repository too)


https://maven-repository.com/artifact/org.freemarker/freemarker

So I'll wait its release to test except if you can explain me how to circumvent 
this issue using my local m2 repository too

Thanks

Jacques

Le 17/01/2019 à 20:13, Daniel Dekany a écrit :

I have added the str?truncate(maxLength) built-in (and its other
variations) to the 2.3-gae head. This is something that users have
requested and implemented their own for who knows how many times, yet
it wasn't added to FreeMarker till now, as there's no single correct
way of text truncation. So what I did is making the algorithm
pluggable, and giving a default that I think reflects a good practice.
I guess most users will just go along (instead of quickly adding some
simplistic #function their own), but those who have other ideas can
still keep using ?truncate.

Please tell your opinions, ideas, or even better, test it!

>From https://freemarker.apache.org/builds/fm2/versions_2_3_29.html:
Added new built-ins for truncating text. string?truncate(length)
truncates the text to the given length, and by default adds [...] at
the end if truncation has happened. Truncation happens at word
boundaries, unless the result is too short that way, in which case it
falls back to truncation mid word. There's also ?truncate_w to force
Word Boundary truncation, and ?truncate_c (for Character Boundary)
that doesn't care about word boundaries. The truncation algorithm is
pluggable in the FreeMarker configuration. See the reference for more
details.

Built-in documentation:
https://freemarker.apache.org/builds/fm2/ref_builtins_string.html#ref_builtin_truncate

Related API-s:
https://freemarker.apache.org/builds/fm2/api/freemarker/core/TruncateBuiltinAlgorithm.html
https://freemarker.apache.org/builds/fm2/api/freemarker/core/DefaultTruncateBuiltinAlgorithm.html
https://freemarker.apache.org/builds/fm2/api/freemarker/core/Configurable.html#setTruncateBuiltinAlgorithm-freemarker.core.TruncateBuiltinAlgorithm-

Commit:
https://github.com/apache/freemarker/commit/7c5ef10ef3da3b94fc5cdf9d61c966282b6cd8ac

Re: Review Board Report draft for the last 3 months

2019-02-11 Thread Jacques Le Roux


Thanks Daniel

Looks good to me

Jacques

Le 11/02/2019 à 08:11, Daniel Dekany a écrit :

Dear PMC members, and all,

Here's the draft of our PMC report, which I will submit at 2019-02-13:
https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft

Please review it, and add to if it something is missing!

Re: [VOTE] Move Git repos from git-wip to gitbox

2018-12-18 Thread Jacques Le Roux


I agree, it's soon mandatory anyway

+1

Jacques

Le 18/12/2018 à 05:28, David E Jones a écrit :

Seems odd to require a consensus vote if it is mandatory in a couple of
months but sure, agreed.

+1

-David


On Mon, Dec 17, 2018 at 2:02 AM Daniel Dekany  wrote:


We should move the FreeMarker repos from git-wip to gitbox, as the
mail quoted below says. As it's needed to demonstrate consensus (or
else... it will be moved later regardless), I made this to be a vote.
So especially PMC members, please reply!

Do you agree that I will request all the FreeMarker repos that are on
git-wip to be moved to gitbox in the coming days?

My vote:
+1


Friday, December 7, 2018, 5:52:36 PM, Daniel Gruno wrote:


[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
   DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]

Hello Apache projects,

I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
months. All repositories will be moved to the new gitbox service which
includes direct write access on github as well as the standard ASF
commit access via gitbox.apache.org.

## Why this move? ##
The move comes as a result of retiring the git-wip service, as the
hardware it runs on is longing for retirement. In lieu of this, we
have decided to consolidate the two services (git-wip and gitbox), to
ease the management of our repository systems and future-proof the
underlying hardware. The move is fully automated, and ideally, nothing
will change in your workflow other than added features and access to
GitHub.

## Timeframe for relocation ##
Initially, we are asking that projects voluntarily request to move
their repositories to gitbox, hence this email. The voluntary
timeframe is between now and January 9th 2019, during which projects
are free to either move over to gitbox or stay put on git-wip. After
this phase, we will be requiring the remaining projects to move within
one month, after which we will move the remaining projects over.

To have your project moved in this initial phase, you will need:

- Consensus in the project (documented via the mailing list)
- File a JIRA ticket with INFRA to voluntarily move your project repos
over to gitbox (as stated, this is highly automated and will take
between a minute and an hour, depending on the size and number of
your repositories)

To sum up the preliminary timeline;

- December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
relocation

- January 9th ->> February 6th: Mandated (coordinated) relocation

- February 7th: All remaining repositories are mass migrated.

This timeline may change to accommodate various scenarios.

## Using GitHub with ASF repositories ##
When your project has moved, you are free to use either the ASF
repository system (gitbox.apache.org) OR GitHub for your development
and code pushes. To be able to use GitHub, please follow the primer
at: https://reference.apache.org/committer/github


We appreciate your understanding of this issue, and hope that your
project can coordinate voluntarily moving your repositories in a
timely manner.

All settings, such as commit mail targets, issue linking, PR
notification schemes etc will automatically be migrated to gitbox as
well.

With regards, Daniel on behalf of ASF Infra.

PS:For inquiries, please reply to us...@infra.apache.org, not your
project's dev list :-).




--
Thanks,
  Daniel Dekany

Re: Review Board Report draft for the last 3 months

2018-11-12 Thread Jacques Le Roux


Sounds good to me, thanks Daniel and David

Jacques


Le 11/11/2018 à 08:42, Daniel Dekany a écrit :

Saturday, November 10, 2018, 10:45:18 PM, David E Jones wrote:


This looks good Daniel, thank you. The only thought I had while reading it
was related to the Oath contribution, might be good to add a quick note
about the IP clearance done on that (PMC responsibility but Board concern
for foundation overall).

Sure, I have added this:

   (The code base was given to the ASF according to
   https://issues.apache.org/jira/browse/LEGAL-418. Required CCLA and
   ICLA-s were received.)


-David


On Sat, Nov 10, 2018 at 11:15 AM Daniel Dekany  wrote:


Here's the Board repot draft, which I plan to submit on 2018-11-14.

https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft

Any comments, additions?

--
Thanks,
  Daniel Dekany

Re: [DISCUSS] Estabilish the "FreeMarker Generator" product

2018-09-11 Thread Jacques Le Roux


+1 I second Woonsan


Le 11/09/2018 à 14:41, Woonsan Ko a écrit :

+1

The plan also seems good to me!

Cheers,

Woonsan

On Tue, Sep 11, 2018 at 3:33 AM Daniel Dekany  wrote:

Dear PMC members,

It would be good to hear the voice of more of you. Even if it's just
"I agree", please respond, so we know that you're aware. This belongs
to "FreeMarker Maven Plugin" thread basically, but I though a
"[DISCUSS]" and a summary might yields more response.

Ben Jackson and Mark Malynn from Oath Inc. has offered contributing
https://github.com/yahoo/freemarker-maven-plugin to the FreeMarker
project. It's a fairly small and new code base (no legal history to
untangle), and aims to allow generating code or other files as part of
a Maven build. (We plan to generalize this a bit later, but see
earlier discussion). I propose that we accept this contribution, and
continue on the following manner:

- Create Git repository "freemarker-generator", add LICENSE and NOTICE
   to it. (This is consistent how we structure things in the 2.x
   branch, i.e., having separate freemarker- repository for
   each product that have independent release/deployment cycles.)

- Wait for the two authors sign an ICLA.

- Wait for Oath Inc. representative to sign a CCLA, listing said two
   authors under "Initial list of designated employees".

- They will change license headers and package names on
   https://github.com/yahoo/freemarker-maven-plugin

- Then they do a pull request on our "freemarker-generator"
   repository, and we merge it. After that, development continues
   directly in our repository. This is the same lightweight approach
   we have followed with freemarker-online-tester, so I'm hoping we can
   do that here as well.

The name of the product will be "Apache FreeMarker Generator" (but it
won't have a separate domain), and the Java package name is
org.apache.freemarker.generator, Maven coordinate
org.apache.freemarker:freemarker-generator-.

Do you agree?

--
Thanks,
  Daniel Dekany

Re: Review Board Report draft for the last month

2018-08-03 Thread Jacques Le Roux




Le 03/08/2018 à 07:58, Daniel Dekany a écrit :

Here's the Board repot draft, which I plan to submit on 2018-08-07.

https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft

Any comments?


+1, sounds good to me

Jacques

Re: Anybody interested in some FM3 parser research?

2018-07-05 Thread Jacques Le Roux


Hi Daniel,

Maybe we could find someone interested in the context of GSCOC. But it's 
perhaps a bit late already?

Jacques


Le 04/07/2018 à 19:28, Daniel Dekany a écrit :

I wonder what parser libraries could help us, in FM3, to separate the
expression language parsing from the top-level language (like
`<#foo>`, `${...}`, etc.) parsing. Or if a hand written parsers is an
acceptable compromise. It would be good if we can change the top-level
syntax and still reuse the expression syntax. (Or, replace the
expression syntax, and reuse the top-level one.) Like, somebody wants
a syntax like `#foo(exp)` instead of `<#foo exp>`, but still reuse the
expression syntax. (For me it was always part of the FM3 agenda,
though might will be proven to be too much...)

While the next item in the FM3 pipeline supposed to be
https://issues.apache.org/jira/browse/FREEMARKER-99 (uniform top-level
syntax, and part of the Dialects feature), maybe this parser
combinator thing changes what parser library we should built upon, in
which case first implementing FREEMARKER-99 on top of JavaCC can be
wasteful (OTOH that can be done right now at least).

So, anybody would enjoy doin a bit of research in this area? Like
recommend a solution, with some minimal proof-of-concept? (Mind you,
FM is kind of sensitive to parsing speed; not all applications can use
caching aggressively, like some might use ?eval and ?interpret quite
much. Also, being able to combine parsers on runtime is nice but not a
requirement. But being able to generate a combined parser at least on
build time is certainly needed.)

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-06-13 Thread Jacques Le Roux


Le 12/06/2018 à 21:43, Daniel Dekany a écrit :

Tuesday, June 12, 2018, 7:48:13 PM, Jacques Le Roux wrote:

[snip]

OK thanks, indeed
sudo curl -X POST http://localhost:8081/tasks/reload-ssl
works :)

All is ready and working manually. I will just check the
/var/log/fmonlinetester/letsencrypt.log tomorrow morning. I use the cron line:
0 0 * * * /opt/fmonlinetester/var/cert-renew.sh >
/var/log/fmonlinetester/letsencrypt.log

Great, thanks!

A small thing though. Scripts should be in bin, not var. And if you
are there anyway, AFAIR I have made /opt/fmonlinetester/var/log (which
links to /var/log/fmonlinetester), in which case it's better to use
that path.


OK, I have done the changes you suggested. The cron job works as expected and 
puts results in log.
I also set MAILTO to priv...@freemarker.apache.org not sure it's a good idea. 
Could be in case of issue.

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-06-12 Thread Jacques Le Roux




Le 12/06/2018 à 18:42, Daniel Dekany a écrit :

Tuesday, June 12, 2018, 6:06:17 PM, Jacques Le Roux wrote:


Hi Daniel,

It's done with an update of the wiki page
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation

But I faced an issue with the cron job, this command:

jleroux@freemarker-vm:/opt/fmonlinetester/var$ sudo curl
https://localhost:8081/tasks/reload-ssl
curl: (35) gnutls_handshake() failed: An unexpected TLS packet was received.

I also tried HTTP, no protocol  and both (//) to no avail so far. I
don't know what I miss, if I miss something

jleroux@freemarker-vm:/opt/fmonlinetester/var$ sudo curl 
localhost:8081/tasks/reload-ssl



Error 405 Method Not Allowed

HTTP ERROR 405
Problem accessing /tasks/reload-ssl. Reason:
    Method Not Allowed



It's HTTP, not HTTPS, and it seems the HTTP method must be POST, not
GET.

OK thanks, indeed
sudo curl -X POST http://localhost:8081/tasks/reload-ssl
works :)

All is ready and working manually. I will just check the 
/var/log/fmonlinetester/letsencrypt.log tomorrow morning. I use the cron line:
0 0 * * * /opt/fmonlinetester/var/cert-renew.sh > 
/var/log/fmonlinetester/letsencrypt.log

Jacques

Jacques


Le 09/06/2018 à 14:31, Jacques Le Roux a écrit :

Yes, I'll take care of that

Thanks for the reminder :)

Jacques


Le 09/06/2018 à 11:26, Daniel Dekany a écrit :

You have intended to do these, to my understanding. You still plan to?


Saturday, May 19, 2018, 1:42:57 PM, Jacques Le Roux wrote:


Inline...

Le 19/05/2018 à 12:02, Daniel Dekany a écrit :

Saturday, May 19, 2018, 11:08:36 AM, Jacques Le Roux wrote:


Yes, the cron job (cert-renew.sh) should be run daily/nightly by root, content:

cerbot renew
openssl pkcs12 -export -out /etc/letsencrypt/live/certificate.p12
-inkey /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem -in
/etc/letsencrypt/live/try.freemarker.apache.org/cert.pem -certfile
/etc/letsencrypt/live/try.freemarker.apache.org/chain.pem -pass
pass:"theKnownPassword" (not copied here)

Though you have posted that password to this mailing list anyway... ;)

Yes indeed, just once, but you'r right I should have used private :/
Anyway we should change it and keep the new one in a specific file
at https://svn.apache.org/repos/private/pmc/freemarker


I think it should not change the rights to read in
/etc/letsencrypt/live (now with fmonlinetester in group)

It would be surprising if it changes it.

Yep, just got surprisingly bitten once, so...


but we should try it manually once and check.

If it does change then we will need to re-add fmonlinetester
in the group at end of cert-renew.sh. I crossed this read issue before as 
jleroux
user, initially the dir was readeable w/o sudo and then not. Not
sure if it's certbot or openssl which did that in my case.

Also I don't think we need to care about change in
/etc/letsencrypt/live/try.freemarker.apache.org/ If they are no
change certificate.p12 will be the
same, no worries.

Of course. It will need to issue that SSL cert reloading curl command
though.

Ah indeed

localhost:8081/tasks/reload-ssl



I think we should not show the "theKnownPassword" in the wiki page...

Yeah, I guess it's better star it out on cwiki. (Though to get the p12
or private key one has to pawn the server anyway... and then he finds
the password too.)

I think https://svn.apache.org/repos/private/pmc/freemarker better fits for all 
private things
For instance the cron job copy and all the rest. And simply refer to private 
things from the wiki


Are there any Let's Encrypt related credentials we should be aware of
(in case you become unavailable)?

Nope, I used only the temporary secret password everywhere and IIRW
it was only when creating the cert from .pem files.


I think "Enter email address (used for urgent renewal and security
notices)" should be priv...@freemarker.apache.org.

I agree! I used mine so far. To be changed like the cert password
Will you handle the job creation and the doc?

Have a good weekend

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-06-12 Thread Jacques Le Roux


Hi Daniel,

It's done with an update of the wiki page 
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation

But I faced an issue with the cron job, this command:

jleroux@freemarker-vm:/opt/fmonlinetester/var$ sudo curl 
https://localhost:8081/tasks/reload-ssl
curl: (35) gnutls_handshake() failed: An unexpected TLS packet was received.

I also tried HTTP, no protocol  and both (//) to no avail so far. I don't know 
what I miss, if I miss something

jleroux@freemarker-vm:/opt/fmonlinetester/var$ sudo curl 
localhost:8081/tasks/reload-ssl



Error 405 Method Not Allowed

HTTP ERROR 405
Problem accessing /tasks/reload-ssl. Reason:
    Method Not Allowed



Jacques


Le 09/06/2018 à 14:31, Jacques Le Roux a écrit :

Yes, I'll take care of that

Thanks for the reminder :)

Jacques


Le 09/06/2018 à 11:26, Daniel Dekany a écrit :

You have intended to do these, to my understanding. You still plan to?


Saturday, May 19, 2018, 1:42:57 PM, Jacques Le Roux wrote:


Inline...

Le 19/05/2018 à 12:02, Daniel Dekany a écrit :

Saturday, May 19, 2018, 11:08:36 AM, Jacques Le Roux wrote:


Yes, the cron job (cert-renew.sh) should be run daily/nightly by root, content:

cerbot renew
openssl pkcs12 -export -out /etc/letsencrypt/live/certificate.p12
-inkey /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem -in
/etc/letsencrypt/live/try.freemarker.apache.org/cert.pem -certfile
/etc/letsencrypt/live/try.freemarker.apache.org/chain.pem -pass
pass:"theKnownPassword" (not copied here)

Though you have posted that password to this mailing list anyway... ;)

Yes indeed, just once, but you'r right I should have used private :/
Anyway we should change it and keep the new one in a specific file
at https://svn.apache.org/repos/private/pmc/freemarker


I think it should not change the rights to read in
/etc/letsencrypt/live (now with fmonlinetester in group)

It would be surprising if it changes it.

Yep, just got surprisingly bitten once, so...


but we should try it manually once and check.

If it does change then we will need to re-add fmonlinetester
in the group at end of cert-renew.sh. I crossed this read issue before as 
jleroux
user, initially the dir was readeable w/o sudo and then not. Not
sure if it's certbot or openssl which did that in my case.

Also I don't think we need to care about change in
/etc/letsencrypt/live/try.freemarker.apache.org/ If they are no
change certificate.p12 will be the
same, no worries.

Of course. It will need to issue that SSL cert reloading curl command
though.

Ah indeed

localhost:8081/tasks/reload-ssl



I think we should not show the "theKnownPassword" in the wiki page...

Yeah, I guess it's better star it out on cwiki. (Though to get the p12
or private key one has to pawn the server anyway... and then he finds
the password too.)

I think https://svn.apache.org/repos/private/pmc/freemarker better fits for all 
private things
For instance the cron job copy and all the rest. And simply refer to private 
things from the wiki


Are there any Let's Encrypt related credentials we should be aware of
(in case you become unavailable)?

Nope, I used only the temporary secret password everywhere and IIRW
it was only when creating the cert from .pem files.


I think "Enter email address (used for urgent renewal and security
notices)" should be priv...@freemarker.apache.org.

I agree! I used mine so far. To be changed like the cert password
Will you handle the job creation and the doc?

Have a good weekend

Jacques

Re: Review Board Report draft for the last month

2018-06-11 Thread Jacques Le Roux


+1 Thanks Daniel!

Jacques


Le 11/06/2018 à 14:55, Woonsan Ko a écrit :

Looks good as well. Thank you very much!

Woonsan


On Mon, Jun 11, 2018 at 4:48 AM, Jacopo Cappellato
 wrote:

Looks good to me, thank you Daniel!

Jacopo

On Sun, Jun 10, 2018 at 8:30 AM Daniel Dekany  wrote:


Here's the Board repot draft, which I will submit on 2018-06-13.

https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft

Any comments?

--
Thanks,
  Daniel Dekany

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-06-09 Thread Jacques Le Roux


Yes, I'll take care of that

Thanks for the reminder :)

Jacques


Le 09/06/2018 à 11:26, Daniel Dekany a écrit :

You have intended to do these, to my understanding. You still plan to?


Saturday, May 19, 2018, 1:42:57 PM, Jacques Le Roux wrote:


Inline...

Le 19/05/2018 à 12:02, Daniel Dekany a écrit :

Saturday, May 19, 2018, 11:08:36 AM, Jacques Le Roux wrote:


Yes, the cron job (cert-renew.sh) should be run daily/nightly by root, content:

cerbot renew
openssl pkcs12 -export -out /etc/letsencrypt/live/certificate.p12
-inkey /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem -in
/etc/letsencrypt/live/try.freemarker.apache.org/cert.pem -certfile
/etc/letsencrypt/live/try.freemarker.apache.org/chain.pem -pass
pass:"theKnownPassword" (not copied here)

Though you have posted that password to this mailing list anyway... ;)

Yes indeed, just once, but you'r right I should have used private :/
Anyway we should change it and keep the new one in a specific file
at https://svn.apache.org/repos/private/pmc/freemarker


I think it should not change the rights to read in
/etc/letsencrypt/live (now with fmonlinetester in group)

It would be surprising if it changes it.

Yep, just got surprisingly bitten once, so...


but we should try it manually once and check.

If it does change then we will need to re-add fmonlinetester
in the group at end of cert-renew.sh. I crossed this read issue before as 
jleroux
user, initially the dir was readeable w/o sudo and then not. Not
sure if it's certbot or openssl which did that in my case.

Also I don't think we need to care about change in
/etc/letsencrypt/live/try.freemarker.apache.org/ If they are no
change certificate.p12 will be the
same, no worries.

Of course. It will need to issue that SSL cert reloading curl command
though.

Ah indeed

localhost:8081/tasks/reload-ssl



I think we should not show the "theKnownPassword" in the wiki page...

Yeah, I guess it's better star it out on cwiki. (Though to get the p12
or private key one has to pawn the server anyway... and then he finds
the password too.)

I think https://svn.apache.org/repos/private/pmc/freemarker better fits for all 
private things
For instance the cron job copy and all the rest. And simply refer to private 
things from the wiki


Are there any Let's Encrypt related credentials we should be aware of
(in case you become unavailable)?

Nope, I used only the temporary secret password everywhere and IIRW
it was only when creating the cert from .pem files.


I think "Enter email address (used for urgent renewal and security
notices)" should be priv...@freemarker.apache.org.

I agree! I used mine so far. To be changed like the cert password
Will you handle the job creation and the doc?

Have a good weekend

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-20 Thread Jacques Le Roux



Le 20/05/2018 à 00:31, Daniel Dekany a écrit :

Saturday, May 19, 2018, 6:02:16 PM, Jacques Le Roux wrote:


Le 19/05/2018 à 14:16, Daniel Dekany a écrit :

I thinkhttps://svn.apache.org/repos/private/pmc/freemarker  better fits for all 
private things
For instance the cron job copy and all the rest. And simply refer to private 
things from the wiki

For try.freemarker these security things doesn't mater much, but in
general, such a repo is not a good place to store security related
sensitive files. People just check it out, and it will be on the
HDD/SDD unencrypted for ever... then the notebook gets stolen or such.


What would you suggest then?

Jacques

Generally (not in this case), mail passwords to me and Jacopo and
maybe Woonsan for safe keeping, with PGP. 3+ guys knows it, hopefully
it won't be gone.

In this case, do we need the password at all? It's stored on the VM,
and if the VM is lost, we just request a new key-value pair from Let's
Encrypt, right?

Right

Or is there some limitation there?

Nope

And actually the
password only worth anything if we also archive the key pair... Well,
I will archive them from the VM, and I guess that's all.


I agree, it's enough

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-19 Thread Jacques Le Roux


Le 19/05/2018 à 12:04, Daniel Dekany a écrit :

Saturday, May 19, 2018, 11:53:04 AM, Jacques Le Roux wrote:


Ah, not a big deal, but should we not restrict read (640) on
/opt/fmonlinetester/etc/freemarker-online.yml ?

It contains the cert secret key...

Sure, go ahead.


Done, I have also removed all the HTTPD config

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-19 Thread Jacques Le Roux


Le 19/05/2018 à 14:16, Daniel Dekany a écrit :

I thinkhttps://svn.apache.org/repos/private/pmc/freemarker  better fits for all 
private things
For instance the cron job copy and all the rest. And simply refer to private 
things from the wiki

For try.freemarker these security things doesn't mater much, but in
general, such a repo is not a good place to store security related
sensitive files. People just check it out, and it will be on the
HDD/SDD unencrypted for ever... then the notebook gets stolen or such.


What would you suggest then?

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-19 Thread Jacques Le Roux


Inline...

Le 19/05/2018 à 12:02, Daniel Dekany a écrit :

Saturday, May 19, 2018, 11:08:36 AM, Jacques Le Roux wrote:


Yes, the cron job (cert-renew.sh) should be run daily/nightly by root, content:

cerbot renew
openssl pkcs12 -export -out /etc/letsencrypt/live/certificate.p12
-inkey /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem -in
/etc/letsencrypt/live/try.freemarker.apache.org/cert.pem -certfile
/etc/letsencrypt/live/try.freemarker.apache.org/chain.pem -pass
pass:"theKnownPassword" (not copied here)

Though you have posted that password to this mailing list anyway... ;)

Yes indeed, just once, but you'r right I should have used private :/
Anyway we should change it and keep the new one in a specific file at 
https://svn.apache.org/repos/private/pmc/freemarker


I think it should not change the rights to read in
/etc/letsencrypt/live (now with fmonlinetester in group)

It would be surprising if it changes it.

Yep, just got surprisingly bitten once, so...




but we should try it manually once and check.

If it does change then we will need to re-add fmonlinetester
in the group at end of cert-renew.sh. I crossed this read issue before as 
jleroux
user, initially the dir was readeable w/o sudo and then not. Not
sure if it's certbot or openssl which did that in my case.

Also I don't think we need to care about change in
/etc/letsencrypt/live/try.freemarker.apache.org/ If they are no
change certificate.p12 will be the
same, no worries.

Of course. It will need to issue that SSL cert reloading curl command
though.

Ah indeed

localhost:8081/tasks/reload-ssl



I think we should not show the "theKnownPassword" in the wiki page...

Yeah, I guess it's better star it out on cwiki. (Though to get the p12
or private key one has to pawn the server anyway... and then he finds
the password too.)

I think https://svn.apache.org/repos/private/pmc/freemarker better fits for all 
private things
For instance the cron job copy and all the rest. And simply refer to private 
things from the wiki


Are there any Let's Encrypt related credentials we should be aware of
(in case you become unavailable)?

Nope, I used only the temporary secret password everywhere and IIRW it was only 
when creating the cert from .pem files.


I think "Enter email address (used for urgent renewal and security
notices)" should be priv...@freemarker.apache.org.

I agree! I used mine so far. To be changed like the cert password
Will you handle the job creation and the doc?

Have a good weekend

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-19 Thread Jacques Le Roux


Ah, not a big deal, but should we not restrict read (640) on 
/opt/fmonlinetester/etc/freemarker-online.yml ?

It contains the cert secret key...


Le 19/05/2018 à 11:08, Jacques Le Roux a écrit :

Yes, the cron job (cert-renew.sh) should be run daily/nightly by root, content:

cerbot renew
openssl pkcs12 -export -out /etc/letsencrypt/live/certificate.p12 -inkey /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem -in 
/etc/letsencrypt/live/try.freemarker.apache.org/cert.pem -certfile /etc/letsencrypt/live/try.freemarker.apache.org/chain.pem -pass 
pass:"theKnownPassword" (not copied here)


I think it should not change the rights to read in /etc/letsencrypt/live (now with fmonlinetester in group) but we should try it manually once and 
check. If it does change then we will need to re-add fmonlinetester in the group at end of cert-renew.sh. I crossed this read issue before as 
jleroux user, initially the dir was readeable w/o sudo and then not. Not sure if it's certbot or openssl which did that in my case.


Also I don't think we need to care about change in /etc/letsencrypt/live/try.freemarker.apache.org/ If they are no change certificate.p12 will be 
the same, no worries.


I think we should not show the "theKnownPassword" in the wiki page...

What do you think?

Jacques


Le 19/05/2018 à 10:32, Daniel Dekany a écrit :

Now https works, and only the cron job and documenting things on the
cwiki is missing (the copy-paste cron script mostly, I guess).


Thursday, May 17, 2018, 7:47:20 PM, Daniel Dekany wrote:


Thursday, May 17, 2018, 3:05:02 PM, Jacques Le Roux wrote:


Le 17/05/2018 à 09:04, Jacques Le Roux a écrit :

Le 16/05/2018 à 22:26, Jacques Le Roux a écrit :

When I read the content in my local Git repo it's commented out. I guess I 
should manually change it on the VM and restart the app with Gradle?

As it's a bit late already, I let you handle this last part ;)

OK I remember now that you documented the app restart at
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation
I'll do so now and will have a look at the code change for the renew

Jacques


I have just changed the file according to my previous message, ie modified to
      keyStorePath: /etc/letsencrypt/live/certificate.p12
      keyStorePassword: HTTPDisUnnecessary
and also while at it (not sure we want that)
      validateCerts: true

But after setting the iptables for 443-8443 (v4 and v6), saving the
change and restarting the app it did not work:

May 17 11:51:06 freemarker-vm systemd[1]: Stopped FreeMarker Online Tester.
May 17 11:51:06 freemarker-vm systemd[1]: Started FreeMarker Online Tester.
May 17 11:52:10 freemarker-vm java[14009]:
MultiException[java.lang.IllegalStateException: no valid keystore,
java.lang.IllegalStateException: no

That was because the service had no right to read the parent directory
of the p12 file. (Yeah, that error message is not very helpful...) I
have fixed that. So now the only problem we have what I said in the
other mail. And we will need the cron script... or maybe a systemd
timer unit instead.


valid keystore, java.util.concurrent.RejectedExecutionException: 
org.eclipse.jetty.io.Manag
May 17 11:52:10 freemarker-vm java[14009]: at
org.eclipse.jetty.server.Server.doStart(Server.java:382)
May 17 11:52:10 freemarker-vm java[14009]: at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.cli.ServerCommand.run(ServerCommand.java:53)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.cli.EnvironmentCommand.run(EnvironmentCommand.java:44)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.cli.ConfiguredCommand.run(ConfiguredCommand.java:87)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.cli.Cli.run(Cli.java:78)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.Application.run(Application.java:93)
May 17 11:52:10 freemarker-vm java[14009]: at
org.apache.freemarker.onlinetester.dropwizard.FreeMarkerOnlineTester.main(FreeMarkerOnlineTester.java:43)

So I commented out the HTTPS part
      #  # FOR PRODUCTION:
      #  - type: https
      #    port: 8443
      #    keyStorePath: /etc/letsencrypt/live/certificate.p12
      #    keyStoreType: PKCS12
      #    keyStorePassword: HTTPDisUnnecessary
      #    validateCerts: true
and restarted the app

Now http://try.freemarker.org/ works again, but no longer
http://try.freemarker.apache.org/ which is redirected to
https://try.freemarker.apache.org/
I don't understand the redirect. Does have this changed before my change? I 
don't know.
I have double-checked, thought I have not reverted the config yet, HTTPD is no 
longer working.
Maybe it's due to the certificate (created for a.o) but I can't see
how

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-19 Thread Jacques Le Roux


Yes, the cron job (cert-renew.sh) should be run daily/nightly by root, content:

cerbot renew
openssl pkcs12 -export -out /etc/letsencrypt/live/certificate.p12 -inkey /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem -in 
/etc/letsencrypt/live/try.freemarker.apache.org/cert.pem -certfile /etc/letsencrypt/live/try.freemarker.apache.org/chain.pem -pass 
pass:"theKnownPassword" (not copied here)


I think it should not change the rights to read in /etc/letsencrypt/live (now with fmonlinetester in group) but we should try it manually once and 
check. If it does change then we will need to re-add fmonlinetester in the group at end of cert-renew.sh. I crossed this read issue before as jleroux 
user, initially the dir was readeable w/o sudo and then not. Not sure if it's certbot or openssl which did that in my case.


Also I don't think we need to care about change in /etc/letsencrypt/live/try.freemarker.apache.org/ If they are no change certificate.p12 will be the 
same, no worries.


I think we should not show the "theKnownPassword" in the wiki page...

What do you think?

Jacques


Le 19/05/2018 à 10:32, Daniel Dekany a écrit :

Now https works, and only the cron job and documenting things on the
cwiki is missing (the copy-paste cron script mostly, I guess).


Thursday, May 17, 2018, 7:47:20 PM, Daniel Dekany wrote:


Thursday, May 17, 2018, 3:05:02 PM, Jacques Le Roux wrote:


Le 17/05/2018 à 09:04, Jacques Le Roux a écrit :

Le 16/05/2018 à 22:26, Jacques Le Roux a écrit :

When I read the content in my local Git repo it's commented out. I guess I 
should manually change it on the VM and restart the app with Gradle?

As it's a bit late already, I let you handle this last part ;)

OK I remember now that you documented the app restart at
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation
I'll do so now and will have a look at the code change for the renew

Jacques


I have just changed the file according to my previous message, ie modified to
      keyStorePath: /etc/letsencrypt/live/certificate.p12
      keyStorePassword: HTTPDisUnnecessary
and also while at it (not sure we want that)
      validateCerts: true

But after setting the iptables for 443-8443 (v4 and v6), saving the
change and restarting the app it did not work:

May 17 11:51:06 freemarker-vm systemd[1]: Stopped FreeMarker Online Tester.
May 17 11:51:06 freemarker-vm systemd[1]: Started FreeMarker Online Tester.
May 17 11:52:10 freemarker-vm java[14009]:
MultiException[java.lang.IllegalStateException: no valid keystore,
java.lang.IllegalStateException: no

That was because the service had no right to read the parent directory
of the p12 file. (Yeah, that error message is not very helpful...) I
have fixed that. So now the only problem we have what I said in the
other mail. And we will need the cron script... or maybe a systemd
timer unit instead.


valid keystore, java.util.concurrent.RejectedExecutionException: 
org.eclipse.jetty.io.Manag
May 17 11:52:10 freemarker-vm java[14009]: at
org.eclipse.jetty.server.Server.doStart(Server.java:382)
May 17 11:52:10 freemarker-vm java[14009]: at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.cli.ServerCommand.run(ServerCommand.java:53)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.cli.EnvironmentCommand.run(EnvironmentCommand.java:44)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.cli.ConfiguredCommand.run(ConfiguredCommand.java:87)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.cli.Cli.run(Cli.java:78)
May 17 11:52:10 freemarker-vm java[14009]: at
io.dropwizard.Application.run(Application.java:93)
May 17 11:52:10 freemarker-vm java[14009]: at
org.apache.freemarker.onlinetester.dropwizard.FreeMarkerOnlineTester.main(FreeMarkerOnlineTester.java:43)

So I commented out the HTTPS part
      #  # FOR PRODUCTION:
      #  - type: https
      #    port: 8443
      #    keyStorePath: /etc/letsencrypt/live/certificate.p12
      #    keyStoreType: PKCS12
      #    keyStorePassword: HTTPDisUnnecessary
      #    validateCerts: true
and restarted the app

Now http://try.freemarker.org/ works again, but no longer
http://try.freemarker.apache.org/ which is redirected to
https://try.freemarker.apache.org/
I don't understand the redirect. Does have this changed before my change? I 
don't know.
I have double-checked, thought I have not reverted the config yet, HTTPD is no 
longer working.
Maybe it's due to the certificate (created for a.o) but I can't see
how DropWizard would now relate to it, since
      keyStorePath: /etc/letsencrypt/live/certificate.p12
and the whole HTTPS block, is commented out :/

I'll get back to that later...

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-17 Thread Jacques Le Roux


Le 17/05/2018 à 09:04, Jacques Le Roux a écrit :

Le 16/05/2018 à 22:26, Jacques Le Roux a écrit :

When I read the content in my local Git repo it's commented out. I guess I 
should manually change it on the VM and restart the app with Gradle?

As it's a bit late already, I let you handle this last part ;)

OK I remember now that you documented the app restart at
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation
I'll do so now and will have a look at the code change for the renew

Jacques


I have just changed the file according to my previous message, ie modified to
    keyStorePath: /etc/letsencrypt/live/certificate.p12
    keyStorePassword: HTTPDisUnnecessary
and also while at it (not sure we want that)
    validateCerts: true

But after setting the iptables for 443-8443 (v4 and v6), saving the change and 
restarting the app it did not work:

May 17 11:51:06 freemarker-vm systemd[1]: Stopped FreeMarker Online Tester.
May 17 11:51:06 freemarker-vm systemd[1]: Started FreeMarker Online Tester.
May 17 11:52:10 freemarker-vm java[14009]: MultiException[java.lang.IllegalStateException: no valid keystore, java.lang.IllegalStateException: no 
valid keystore, java.util.concurrent.RejectedExecutionException: org.eclipse.jetty.io.Manag

May 17 11:52:10 freemarker-vm java[14009]: at 
org.eclipse.jetty.server.Server.doStart(Server.java:382)
May 17 11:52:10 freemarker-vm java[14009]: at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
May 17 11:52:10 freemarker-vm java[14009]: at 
io.dropwizard.cli.ServerCommand.run(ServerCommand.java:53)
May 17 11:52:10 freemarker-vm java[14009]: at 
io.dropwizard.cli.EnvironmentCommand.run(EnvironmentCommand.java:44)
May 17 11:52:10 freemarker-vm java[14009]: at 
io.dropwizard.cli.ConfiguredCommand.run(ConfiguredCommand.java:87)
May 17 11:52:10 freemarker-vm java[14009]: at 
io.dropwizard.cli.Cli.run(Cli.java:78)
May 17 11:52:10 freemarker-vm java[14009]: at 
io.dropwizard.Application.run(Application.java:93)
May 17 11:52:10 freemarker-vm java[14009]: at 
org.apache.freemarker.onlinetester.dropwizard.FreeMarkerOnlineTester.main(FreeMarkerOnlineTester.java:43)


So I commented out the HTTPS part
    #  # FOR PRODUCTION:
    #  - type: https
    #    port: 8443
    #    keyStorePath: /etc/letsencrypt/live/certificate.p12
    #    keyStoreType: PKCS12
    #    keyStorePassword: HTTPDisUnnecessary
    #    validateCerts: true
and restarted the app

Now http://try.freemarker.org/ works again, but no longer 
http://try.freemarker.apache.org/ which is redirected to 
https://try.freemarker.apache.org/
I don't understand the redirect. Does have this changed before my change? I 
don't know.
I have double-checked, thought I have not reverted the config yet, HTTPD is no 
longer working.
Maybe it's due to the certificate (created for a.o) but I can't see how 
DropWizard would now relate to it, since
    keyStorePath: /etc/letsencrypt/live/certificate.p12
and the whole HTTPS block, is commented out :/

I'll get back to that later...

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-17 Thread Jacques Le Roux


Le 16/05/2018 à 22:26, Jacques Le Roux a écrit :

When I read the content in my local Git repo it's commented out. I guess I 
should manually change it on the VM and restart the app with Gradle?

As it's a bit late already, I let you handle this last part ;)

OK I remember now that you documented the app restart at
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation
I'll do so now and will have a look at the code change for the renew

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-16 Thread Jacques Le Roux


Hi Daniel,

I guess I should now change

#    keyStorePath: /etc/letsencrypt/live/example.p12
#    keyStorePassword: secret
in freemarker-online.yml

to

#    keyStorePath: /etc/letsencrypt/live/certificate.p12
#    keyStorePassword: theRightPassword ;)

When I read the content in my local Git repo it's commented out. I guess I 
should manually change it on the VM and restart the app with Gradle?

As it's a bit late already, I let you handle this last part ;)

We have still to look at how renew the certificate using cron...

Thanks

Jacques


Le 16/05/2018 à 21:54, Jacques Le Roux a écrit :

Le 16/05/2018 à 21:54, Jacques Le Roux a écrit :

Le 15/05/2018 à 21:58, Daniel Dekany a écrit :

It's going to be something like

   certbot certonly --webroot -w 
/opt/fmonlinetester/var/letsencrypt-acme-challenge

Almost, we just needed to add the domains (else it asks for one)

jleroux@freemarker-vm:~$ sudo certbot certonly --webroot -w /opt/fmonlinetester/var/letsencrypt-acme-challenge -d try.freemarker.apache.org -d 
try.freemarker.org

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): jler...@apache.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org

---
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
---
(A)gree/(C)ancel: A

---
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
---
(Y)es/(N)o: N
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for try.freemarker.apache.org
http-01 challenge for try.freemarker.org
Using the webroot path /opt/fmonlinetester/var/letsencrypt-acme-challenge for 
all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/try.freemarker.apache.org/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem
   Your cert will expire on 2018-08-14. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
   Donating to EFF:    https://eff.org/donate-le

I have then used
openssl pkcs12 -export -out /etc/letsencrypt/live/certificate.p12 -inkey /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem -in 
/etc/letsencrypt/live/try.freemarker.apache.org/cert.pem -certfile /etc/letsencrypt/live/try.freemarker.apache.org/chain.pem

with pwd in next message
Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-16 Thread Jacques Le Roux


Le 16/05/2018 à 21:54, Jacques Le Roux a écrit :

Le 15/05/2018 à 21:58, Daniel Dekany a écrit :

It's going to be something like

   certbot certonly --webroot -w 
/opt/fmonlinetester/var/letsencrypt-acme-challenge

Almost, we just needed to add the domains (else it asks for one)

jleroux@freemarker-vm:~$ sudo certbot certonly --webroot -w /opt/fmonlinetester/var/letsencrypt-acme-challenge -d try.freemarker.apache.org -d 
try.freemarker.org

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): jler...@apache.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org

---
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
---
(A)gree/(C)ancel: A

---
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
---
(Y)es/(N)o: N
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for try.freemarker.apache.org
http-01 challenge for try.freemarker.org
Using the webroot path /opt/fmonlinetester/var/letsencrypt-acme-challenge for 
all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/try.freemarker.apache.org/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem
   Your cert will expire on 2018-08-14. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
   Donating to EFF:    https://eff.org/donate-le

I have then used
openssl pkcs12 -export -out /etc/letsencrypt/live/certificate.p12 -inkey /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem -in 
/etc/letsencrypt/live/try.freemarker.apache.org/cert.pem -certfile /etc/letsencrypt/live/try.freemarker.apache.org/chain.pem

with pwd in next message

pwd: HTTPDisUnnecessary


Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-16 Thread Jacques Le Roux


Le 15/05/2018 à 21:58, Daniel Dekany a écrit :

It's going to be something like

   certbot certonly --webroot -w 
/opt/fmonlinetester/var/letsencrypt-acme-challenge

Almost, we just needed to add the domains (else it asks for one)

jleroux@freemarker-vm:~$ sudo certbot certonly --webroot -w /opt/fmonlinetester/var/letsencrypt-acme-challenge -d try.freemarker.apache.org -d 
try.freemarker.org

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): jler...@apache.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org

---
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
---
(A)gree/(C)ancel: A

---
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
---
(Y)es/(N)o: N
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for try.freemarker.apache.org
http-01 challenge for try.freemarker.org
Using the webroot path /opt/fmonlinetester/var/letsencrypt-acme-challenge for 
all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/try.freemarker.apache.org/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem
   Your cert will expire on 2018-08-14. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
   Donating to EFF:    https://eff.org/donate-le

I have then used
openssl pkcs12 -export -out /etc/letsencrypt/live/certificate.p12 -inkey /etc/letsencrypt/live/try.freemarker.apache.org/privkey.pem -in 
/etc/letsencrypt/live/try.freemarker.apache.org/cert.pem -certfile /etc/letsencrypt/live/try.freemarker.apache.org/chain.pem

with pwd in next message

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-16 Thread Jacques Le Roux


Le 15/05/2018 à 21:58, Daniel Dekany a écrit :

And, don't install httpd now suddenly... that part of the problem is
solved, we don't need it. It's going to be something like

Actually HTTPD is installed by default on all ASF VMs (no surprise, it's 
initially the HTTPD foundation after all ;))
I have already stopped it yesterday so I have only to get back to the default 
config (a very simple one). I'll do that when all will be clear.

Jacques

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-15 Thread Jacques Le Roux

Thanks Daniel,

I'll have another look...

Cheers

Jacques

Le 15/05/2018 à 21:58, Daniel Dekany a écrit :

Actually, the I have just see that the challenge directory must be
/.well-known/acme-challenge/, so now it's that:
http://try.freemarker.org/.well-known/acme-challenge/test.txt
http://try.freemarker.apache.org/.well-known/acme-challenge/test.txt
Also, now it doesn't redirect to HTTPS.

And, don't install httpd now suddenly... that part of the problem is
solved, we don't need it. It's going to be something like

certbot certonly --webroot -w
/opt/fmonlinetester/var/letsencrypt-acme-challenge

Tuesday, May 15, 2018, 8:43:06 PM, Daniel Dekany wrote:

OK, so now hopefully it's ready for Let's Encrypt.

In /opt/fmonlinetester/etc/freemarker-online.yml you can see:

- That now it also server with HTTPS, in additionally to HTTP.
For now it uses /etc/letsencrypt/live/example.p12; it's just an example
(I'm not even sure if the directory will be that.)

- Dropwizard will need a standard p12 file. (No need for JKS, though that works
as well.)

- /opt/fmonlinetester/var/letsencrypt-verify is served as static
content. Try this: http://try.freemarker.org/letsencrypt-verify
So that's what certbot will have to overwrite for the verification.

- http://try.apache.freemarker.org/ redirect to
https://try.apache.freemarker.org/
Now that I think about it, I'm not sure if Let's Encrypt will like
that during the vertification... with our example cert... well,
let's hope it does.

When cerbot is run by cron (I guess it does), then two extra steps
will be needed:

1. Converting to p12 format.
2. Trigger SSL certificate reloading with curl (POST to
localhost:8081/tasks/reload-ssl)

Examples:
https://nbsoftsolutions.com/blog/dropwizard-1-1-and-lets-encrypt-with-no-downtime
https://danielflower.github.io/2017/04/08/Lets-Encrypt-Certs-with-embedded-Jetty.html

(Again, we don't need to convert the p12 further to jks... the p12 is
already good.)

Tuesday, May 15, 2018, 7:49:44 PM, Daniel Dekany wrote:

Ugh. OK, I have Googled into how certbot works, and it requres a few
things from HTTP service itself... I will upload a new version of the
Dropwizard app that can do those things soon.

Tuesday, May 15, 2018, 4:14:55 PM, Daniel Dekany wrote:

Tuesday, May 15, 2018, 2:26:14 PM, Jacques Le Roux wrote:

Hi Daniel,

I have closed INFRA-16498, we can do it locally, Puppet is not used.

So I will use letsencrypt to create a certificate for the 2 domains
try.freemarker.org and try.freemarker.apache.org

At
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation

I read that the port 22 and 80 are accessible from Internet and that Java
serves at port 8080.

As I'm used to it, I want to use HTTPD + AJP with the port 443 and
to replace the iptable redirection by AJP

There's no AJP or any such mess. It's just a Dropwizard (Java)
application (single runnable jar) with an embedded HTTP server, that
server everything directly. Well, except that we need the iptables
port redirection as we have no right to bind to ports < 1024... but
that's all.

but

1. Why do we need the port 22?

For SSH.

2. I think we don't need to serve the port 8443 from Java and can
redirect the port 443 to the port 8080, right? Not sure about that, maybe a
change
in code is needed?

No, port 8080 corresponds to port 80. Dropwizard (Java) will serve
https on 8443 (I assume), which should corresponds to 443 via
iptables.

3. I understand (did not check the whole code) that it does not
use a web server like Tomcat or Jetty (to handle AJP) but Jersey+Grizzly, right?

It uses embedded Jetty, but configure Dropwizard itself:
https://www.dropwizard.io/1.3.2/docs/manual/core.html#ssl

4. I read that Grizzly supports AJP[1] but I don't know yet how it
does, same way than Tomcat, nothing to add?

Because when I try to install a letsencrypt certificate with
certbot as root I can't. Using www-data user (HTTPD default user for User and
Group on
Debian in apache2.conf) I get: (I also tried fmonlinetester user in case)

certbot --apache

[... all correct so far]

Performing the following challenges:
http-01 challenge for try.freemarker.apache.org
http-01 challenge for try.freemarker.org
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. try.freemarker.apache.org
(http-01): urn:acme:error:unauthorized :: The client lacks sufficient
authorization ::
Invalid response from
http://try.freemarker.apache.org/.well-known/acme-challenge/ZXA7ZVpVHW4JHl-UnOnSOnsxTZkknbfyG94F0O4BPRI
[54.71.67.193]: 404,
try.freemarker.org (http-01): urn:acme:error:unauthorized :: The
client lacks sufficient authorization :: Invalid response from
http://try.freemarker.org/.well-known/acme-challenge/XM0ZwcY91Hdn67kNkRAqHj0_SRC1esu8avbVZYTVe2k
[54.71.67.193]: 404

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-15 Thread Jacques Le Roux

Hi Daniel,

I have closed INFRA-16498, we can do it locally, Puppet is not used.

So I will use letsencrypt to create a certificate for the 2 domains
try.freemarker.org and try.freemarker.apache.org

At
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation

I read that the port 22 and 80 are accessible from Internet and that Java
serves at port 8080.

As I'm used to it, I want to use HTTPD + AJP with the port 443 and to replace
the iptable redirection by AJP

but

1. Why do we need the port 22?
2. I think we don't need to serve the port 8443 from Java and can redirect the
port 443 to the port 8080, right? Not sure about that, maybe a change
in code is needed?
3. I understand (did not check the whole code) that it does not use a web
server like Tomcat or Jetty (to handle AJP) but Jersey+Grizzly, right?
4. I read that Grizzly supports AJP[1] but I don't know yet how it does, same
way than Tomcat, nothing to add?

Because when I try to install a letsencrypt certificate with certbot as root I can't. Using www-data user (HTTPD default user for User and Group on
Debian in apache2.conf) I get: (I also tried fmonlinetester user in case)

certbot --apache

[... all correct so far]

Performing the following challenges:
http-01 challenge for try.freemarker.apache.org
http-01 challenge for try.freemarker.org
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. try.freemarker.apache.org (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization ::
Invalid response from http://try.freemarker.apache.org/.well-known/acme-challenge/ZXA7ZVpVHW4JHl-UnOnSOnsxTZkknbfyG94F0O4BPRI [54.71.67.193]: 404,
try.freemarker.org (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from
http://try.freemarker.org/.well-known/acme-challenge/XM0ZwcY91Hdn67kNkRAqHj0_SRC1esu8avbVZYTVe2k [54.71.67.193]: 404

IMPORTANT NOTES:
- The following errors were reported by the server:

Domain: try.freemarker.apache.org
Type: unauthorized
Detail: Invalid response from
http://try.freemarker.apache.org/.well-known/acme-challenge/ZXA7ZVpVHW4JHl-UnOnSOnsxTZkknbfyG94F0O4BPRI
[54.71.67.193]: 404

Domain: try.freemarker.org
Type: unauthorized
Detail: Invalid response from
http://try.freemarker.org/.well-known/acme-challenge/XM0ZwcY91Hdn67kNkRAqHj0_SRC1esu8avbVZYTVe2k
[54.71.67.193]: 404

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/ record(s) for that domain
contain(s) the right IP address.

[domains are correct and 54.71.67.193 is currently the right IP]

- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.

[I have removed /etc/letsencryptn it's of no use as long as long as the
challenges are not successful[2]]

Obviously certbot is not able to put the challenge file where it needs.

So it seems a change in code is needed? Else what would you suggest?

Jacques

[1] https://javaee.github.io/grizzly/ajp.html

[2]
https://superuser.com/questions/1194523/lets-encrypt-certbot-where-is-the-private-key

Le 08/05/2018 à 14:25, Jacques Le Roux a écrit :

It's OK now with Chris Lambertus's help

I created https://issues.apache.org/jira/browse/INFRA-16498 to continue

Jacques

Le 06/05/2018 à 09:10, Jacques Le Roux a écrit :

Thanks

Just tried, did not work, not sure why

Le 05/05/2018 à 19:05, Daniel Dekany a écrit :

I'm a sudoer, so I can add you. Try now!

Saturday, May 5, 2018, 3:07:13 PM, Jacques Le Roux wrote:

Thanks Daniel,

I did not, but actually as I'm not in the sudoers it does not help:

otp-md5 499 fr516
Password:
jleroux is not in the sudoers file. This incident will be reported.
jleroux@freemarker-vm:~$

Jacques

Le 05/05/2018 à 12:38, Daniel Dekany a écrit :

Saturday, May 5, 2018, 11:24:37 AM, Jacques Le Roux wrote:

I asked for sudo: https://issues.apache.org/jira/browse/INFRA-15775

Have you done the OTP stuff? See on:
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation

Jacques

Le 01/05/2018 à 14:50, Jacques Le Roux a écrit :

Hi Daniel,

Yes completely forgot about that. I just checked and I have access to the VM.

Since we need to do it ourselves, I'll have a look, hopefully this week (very
possible)

Cheers

Jacques

Le 30/04/2018 à 16:51, Daniel Dekany a écrit :

Seems this was forgotten. Do you plan to do it?

Monday, January 8, 2018, 11:04:31 AM, Jacques Le Roux wrote:

Thanks Daniel,

That's a good news. I did not want to get further with
try.freemarker.org waiting for this to happen. Once Lets

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-08 Thread Jacques Le Roux


It's OK now with Chris Lambertus's help

I created https://issues.apache.org/jira/browse/INFRA-16498 to continue

Jacques


Le 06/05/2018 à 09:10, Jacques Le Roux a écrit :

Thanks

Just tried, did not work, not sure why


Le 05/05/2018 à 19:05, Daniel Dekany a écrit :

I'm a sudoer, so I can add you. Try now!


Saturday, May 5, 2018, 3:07:13 PM, Jacques Le Roux wrote:


Thanks Daniel,

I did not, but actually as I'm not in the sudoers it does not help:

otp-md5 499 fr516
Password:
jleroux is not in the sudoers file.  This incident will be reported.
jleroux@freemarker-vm:~$

Jacques


Le 05/05/2018 à 12:38, Daniel Dekany a écrit :

Saturday, May 5, 2018, 11:24:37 AM, Jacques Le Roux wrote:


I asked for sudo: https://issues.apache.org/jira/browse/INFRA-15775

Have you done the OTP stuff? See on:
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation


Jacques


Le 01/05/2018 à 14:50, Jacques Le Roux a écrit :

Hi Daniel,

Yes completely forgot about that. I just checked and I have access to the VM.

Since we need to do it ourselves, I'll have a look, hopefully this week (very 
possible)

Cheers

Jacques


Le 30/04/2018 à 16:51, Daniel Dekany a écrit :

Seems this was forgotten. Do you plan to do it?


Monday, January 8, 2018, 11:04:31 AM, Jacques Le Roux wrote:


Thanks Daniel,

That's a good news. I did not want to get further with
try.freemarker.org waiting for this to happen. Once LetsEncrypt setting is done 
a redirection
should be enough

Jacques

Le 08/01/2018 à 09:47, Daniel Dekany a écrit :

Greg commented on the request:

      try.freemarker.apache.org now works, and is propagated.

      Since that hostname maps to your VM, the certificate to be used for
      try.freemarker.apache.org will need to be hosted/operated by your VM.
      Infra's current policy for project VMs is to use LetsEncrypt for
      certificates. [~pono] will get you set up with that.


Wednesday, January 3, 2018, 11:34:32 PM, Jacques Le Roux wrote:


Good, Greg closed INFRA-15476

Jacques

Le 03/01/2018 à 21:23, Daniel Dekany a écrit :

I'm "a bit" late with this, but I have created the issue for it:
https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-15775


Friday, December 15, 2017, 1:57:04 PM, Daniel Dekany wrote:


To summarize, the opininos were (whether we should switch to 
try.freemarker.apache.org):
- Daniel Dekany: We better not risk not doing this
- Jacopo Cappellato: Agrees with me (above) in this
- Jacques Le Roux: No opinion was expressed, but it's technically fine
- Ralph Goers: It's certainly not necessary to do

So, unless someone has more to add, I will ask this from Infra in the
coming days... just to be on the safe side.

Wednesday, November 29, 2017, 6:38:05 PM, Ralph Goers wrote:


The difference is that try.freemarker.org
<http://try.freemarker.org/> is a companion site. So long as the
main site is freemarker.apache.org I don’t think anyone will complain about a 
companion site.

Ralph


On Nov 29, 2017, at 8:33 AM, Jacques Le Roux  
wrote:

Hi Ralph,

IIRW openoffice.org is an exception. There are others, when the domain was well 
established before entering the incubator, subversion.org
comes to mind.

IMO freemarker.org was well established before entering the incubator but not 
try.freemarker.apache.org which is quite recent. Hence maybe
some caution needed...

My 2 cts

Jacques


Le 29/11/2017 à 14:55, Ralph Goers a écrit :

Personally, I don’t see why there should be a problem as long as try.freemarker.org 
<http://try.freemarker.org/> is an Apache controlled
domain. You aren’t the only project that has a vanity domain. See www.openoffice.org 
<http://www.openoffice.org/> as an example.

Ralph


On Nov 29, 2017, at 1:51 AM, Daniel Dekany  wrote:

Just as a reminder, I'm planning to request try.freemarker.apache.org,
from Infra and then redirect try.freemarker.org to it, because I'm
worried that the IPMC will dislike that we use try.freemarker.org as
the canonical address of the online template tester. It will also use
https and a LetsEncrypt certificate (we can't use the *.apache.org
cert on a VM).

BTW, using a sub-sub domains is a bit extreme. I'm not aware of any
gotchas in out case, but if anyone is aware some, like LetsEncrypt
doesn't support them or something, please stop me! (Also, as this way
we will receive the cookies of freemarker.apache.org, but certainly we
will able to cope with that, if it ever causes a problem.)

Any comments? And do you (especially PPMC members) agree?

--
Thanks,
Daniel Dekany

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-06 Thread Jacques Le Roux


Thanks

Just tried, did not work, not sure why


Le 05/05/2018 à 19:05, Daniel Dekany a écrit :

I'm a sudoer, so I can add you. Try now!


Saturday, May 5, 2018, 3:07:13 PM, Jacques Le Roux wrote:


Thanks Daniel,

I did not, but actually as I'm not in the sudoers it does not help:

otp-md5 499 fr516
Password:
jleroux is not in the sudoers file.  This incident will be reported.
jleroux@freemarker-vm:~$

Jacques


Le 05/05/2018 à 12:38, Daniel Dekany a écrit :

Saturday, May 5, 2018, 11:24:37 AM, Jacques Le Roux wrote:


I asked for sudo: https://issues.apache.org/jira/browse/INFRA-15775

Have you done the OTP stuff? See on:
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation


Jacques


Le 01/05/2018 à 14:50, Jacques Le Roux a écrit :

Hi Daniel,

Yes completely forgot about that. I just checked and I have access to the VM.

Since we need to do it ourselves, I'll have a look, hopefully this week (very 
possible)

Cheers

Jacques


Le 30/04/2018 à 16:51, Daniel Dekany a écrit :

Seems this was forgotten. Do you plan to do it?


Monday, January 8, 2018, 11:04:31 AM, Jacques Le Roux wrote:


Thanks Daniel,

That's a good news. I did not want to get further with
try.freemarker.org waiting for this to happen. Once LetsEncrypt setting is done 
a redirection
should be enough

Jacques

Le 08/01/2018 à 09:47, Daniel Dekany a écrit :

Greg commented on the request:

      try.freemarker.apache.org now works, and is propagated.

      Since that hostname maps to your VM, the certificate to be used for
      try.freemarker.apache.org will need to be hosted/operated by your VM.
      Infra's current policy for project VMs is to use LetsEncrypt for
      certificates. [~pono] will get you set up with that.


Wednesday, January 3, 2018, 11:34:32 PM, Jacques Le Roux wrote:


Good, Greg closed INFRA-15476

Jacques

Le 03/01/2018 à 21:23, Daniel Dekany a écrit :

I'm "a bit" late with this, but I have created the issue for it:
https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-15775


Friday, December 15, 2017, 1:57:04 PM, Daniel Dekany wrote:


To summarize, the opininos were (whether we should switch to 
try.freemarker.apache.org):
- Daniel Dekany: We better not risk not doing this
- Jacopo Cappellato: Agrees with me (above) in this
- Jacques Le Roux: No opinion was expressed, but it's technically fine
- Ralph Goers: It's certainly not necessary to do

So, unless someone has more to add, I will ask this from Infra in the
coming days... just to be on the safe side.

Wednesday, November 29, 2017, 6:38:05 PM, Ralph Goers wrote:


The difference is that try.freemarker.org
<http://try.freemarker.org/> is a companion site. So long as the
main site is freemarker.apache.org I don’t think anyone will complain about a 
companion site.

Ralph


On Nov 29, 2017, at 8:33 AM, Jacques Le Roux  
wrote:

Hi Ralph,

IIRW openoffice.org is an exception. There are others, when the domain was well 
established before entering the incubator, subversion.org
comes to mind.

IMO freemarker.org was well established before entering the incubator but not 
try.freemarker.apache.org which is quite recent. Hence maybe
some caution needed...

My 2 cts

Jacques


Le 29/11/2017 à 14:55, Ralph Goers a écrit :

Personally, I don’t see why there should be a problem as long as try.freemarker.org 
<http://try.freemarker.org/> is an Apache controlled
domain. You aren’t the only project that has a vanity domain. See www.openoffice.org 
<http://www.openoffice.org/> as an example.

Ralph


On Nov 29, 2017, at 1:51 AM, Daniel Dekany  wrote:

Just as a reminder, I'm planning to request try.freemarker.apache.org,
from Infra and then redirect try.freemarker.org to it, because I'm
worried that the IPMC will dislike that we use try.freemarker.org as
the canonical address of the online template tester. It will also use
https and a LetsEncrypt certificate (we can't use the *.apache.org
cert on a VM).

BTW, using a sub-sub domains is a bit extreme. I'm not aware of any
gotchas in out case, but if anyone is aware some, like LetsEncrypt
doesn't support them or something, please stop me! (Also, as this way
we will receive the cookies of freemarker.apache.org, but certainly we
will able to cope with that, if it ever causes a problem.)

Any comments? And do you (especially PPMC members) agree?

--
Thanks,
Daniel Dekany

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-05 Thread Jacques Le Roux


Thanks Daniel,

I did not, but actually as I'm not in the sudoers it does not help:

otp-md5 499 fr516
Password:
jleroux is not in the sudoers file.  This incident will be reported.
jleroux@freemarker-vm:~$

Jacques


Le 05/05/2018 à 12:38, Daniel Dekany a écrit :

Saturday, May 5, 2018, 11:24:37 AM, Jacques Le Roux wrote:


I asked for sudo: https://issues.apache.org/jira/browse/INFRA-15775

Have you done the OTP stuff? See on:
https://cwiki.apache.org/confluence/display/FREEMARKER/try.freemarker.org+maintenance+and+installation


Jacques


Le 01/05/2018 à 14:50, Jacques Le Roux a écrit :

Hi Daniel,

Yes completely forgot about that. I just checked and I have access to the VM.

Since we need to do it ourselves, I'll have a look, hopefully this week (very 
possible)

Cheers

Jacques


Le 30/04/2018 à 16:51, Daniel Dekany a écrit :

Seems this was forgotten. Do you plan to do it?


Monday, January 8, 2018, 11:04:31 AM, Jacques Le Roux wrote:


Thanks Daniel,

That's a good news. I did not want to get further with
try.freemarker.org waiting for this to happen. Once LetsEncrypt setting is done 
a redirection
should be enough

Jacques

Le 08/01/2018 à 09:47, Daniel Dekany a écrit :

Greg commented on the request:

     try.freemarker.apache.org now works, and is propagated.

     Since that hostname maps to your VM, the certificate to be used for
     try.freemarker.apache.org will need to be hosted/operated by your VM.
     Infra's current policy for project VMs is to use LetsEncrypt for
     certificates. [~pono] will get you set up with that.


Wednesday, January 3, 2018, 11:34:32 PM, Jacques Le Roux wrote:


Good, Greg closed INFRA-15476

Jacques

Le 03/01/2018 à 21:23, Daniel Dekany a écrit :

I'm "a bit" late with this, but I have created the issue for it:
https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-15775


Friday, December 15, 2017, 1:57:04 PM, Daniel Dekany wrote:


To summarize, the opininos were (whether we should switch to 
try.freemarker.apache.org):
- Daniel Dekany: We better not risk not doing this
- Jacopo Cappellato: Agrees with me (above) in this
- Jacques Le Roux: No opinion was expressed, but it's technically fine
- Ralph Goers: It's certainly not necessary to do

So, unless someone has more to add, I will ask this from Infra in the
coming days... just to be on the safe side.

Wednesday, November 29, 2017, 6:38:05 PM, Ralph Goers wrote:


The difference is that try.freemarker.org
<http://try.freemarker.org/> is a companion site. So long as the
main site is freemarker.apache.org I don’t think anyone will complain about a 
companion site.

Ralph


On Nov 29, 2017, at 8:33 AM, Jacques Le Roux  
wrote:

Hi Ralph,

IIRW openoffice.org is an exception. There are others, when the domain was well 
established before entering the incubator, subversion.org
comes to mind.

IMO freemarker.org was well established before entering the incubator but not 
try.freemarker.apache.org which is quite recent. Hence maybe
some caution needed...

My 2 cts

Jacques


Le 29/11/2017 à 14:55, Ralph Goers a écrit :

Personally, I don’t see why there should be a problem as long as try.freemarker.org 
<http://try.freemarker.org/> is an Apache controlled
domain. You aren’t the only project that has a vanity domain. See www.openoffice.org 
<http://www.openoffice.org/> as an example.

Ralph


On Nov 29, 2017, at 1:51 AM, Daniel Dekany  wrote:

Just as a reminder, I'm planning to request try.freemarker.apache.org,
from Infra and then redirect try.freemarker.org to it, because I'm
worried that the IPMC will dislike that we use try.freemarker.org as
the canonical address of the online template tester. It will also use
https and a LetsEncrypt certificate (we can't use the *.apache.org
cert on a VM).

BTW, using a sub-sub domains is a bit extreme. I'm not aware of any
gotchas in out case, but if anyone is aware some, like LetsEncrypt
doesn't support them or something, please stop me! (Also, as this way
we will receive the cookies of freemarker.apache.org, but certainly we
will able to cope with that, if it ever causes a problem.)

Any comments? And do you (especially PPMC members) agree?

--
Thanks,
Daniel Dekany

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-05 Thread Jacques Le Roux

I asked for sudo: https://issues.apache.org/jira/browse/INFRA-15775

Jacques

Le 01/05/2018 à 14:50, Jacques Le Roux a écrit :

Hi Daniel,

Yes completely forgot about that. I just checked and I have access to the VM.

Since we need to do it ourselves, I'll have a look, hopefully this week (very
possible)

Cheers

Jacques

Le 30/04/2018 à 16:51, Daniel Dekany a écrit :

Seems this was forgotten. Do you plan to do it?

Monday, January 8, 2018, 11:04:31 AM, Jacques Le Roux wrote:

Thanks Daniel,

That's a good news. I did not want to get further with
try.freemarker.org waiting for this to happen. Once LetsEncrypt setting is done
a redirection
should be enough

Jacques

Le 08/01/2018 à 09:47, Daniel Dekany a écrit :

Greg commented on the request:

try.freemarker.apache.org now works, and is propagated.

Since that hostname maps to your VM, the certificate to be used for
try.freemarker.apache.org will need to be hosted/operated by your VM.
Infra's current policy for project VMs is to use LetsEncrypt for
certificates. [~pono] will get you set up with that.

Wednesday, January 3, 2018, 11:34:32 PM, Jacques Le Roux wrote:

Good, Greg closed INFRA-15476

Jacques

Le 03/01/2018 à 21:23, Daniel Dekany a écrit :

I'm "a bit" late with this, but I have created the issue for it:
https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-15775

Friday, December 15, 2017, 1:57:04 PM, Daniel Dekany wrote:

To summarize, the opininos were (whether we should switch to
try.freemarker.apache.org):
- Daniel Dekany: We better not risk not doing this
- Jacopo Cappellato: Agrees with me (above) in this
- Jacques Le Roux: No opinion was expressed, but it's technically fine
- Ralph Goers: It's certainly not necessary to do

So, unless someone has more to add, I will ask this from Infra in the
coming days... just to be on the safe side.

Wednesday, November 29, 2017, 6:38:05 PM, Ralph Goers wrote:

The difference is that try.freemarker.org
<http://try.freemarker.org/> is a companion site. So long as the
main site is freemarker.apache.org I don’t think anyone will complain about a
companion site.

Ralph

On Nov 29, 2017, at 8:33 AM, Jacques Le Roux
wrote:

Hi Ralph,

IIRW openoffice.org is an exception. There are others, when the domain was well established before entering the incubator, subversion.org
comes to mind.

IMO freemarker.org was well established before entering the incubator but not try.freemarker.apache.org which is quite recent. Hence maybe
some caution needed...

My 2 cts

Jacques

Le 29/11/2017 à 14:55, Ralph Goers a écrit :
Personally, I don’t see why there should be a problem as long as try.freemarker.org <http://try.freemarker.org/> is an Apache controlled
domain. You aren’t the only project that has a vanity domain. See www.openoffice.org <http://www.openoffice.org/> as an example.

Ralph

On Nov 29, 2017, at 1:51 AM, Daniel Dekany wrote:

Just as a reminder, I'm planning to request try.freemarker.apache.org,
from Infra and then redirect try.freemarker.org to it, because I'm
worried that the IPMC will dislike that we use try.freemarker.org as
the canonical address of the online template tester. It will also use
https and a LetsEncrypt certificate (we can't use the *.apache.org
cert on a VM).

BTW, using a sub-sub domains is a bit extreme. I'm not aware of any
gotchas in out case, but if anyone is aware some, like LetsEncrypt
doesn't support them or something, please stop me! (Also, as this way
we will receive the cookies of freemarker.apache.org, but certainly we
will able to cope with that, if it ever causes a problem.)

Any comments? And do you (especially PPMC members) agree?

--
Thanks,
Daniel Dekany

Re: try.freemarker.apache.org instead of try.freemarker.org?

2018-05-01 Thread Jacques Le Roux


Hi Daniel,

Yes completely forgot about that. I just checked and I have access to the VM.

Since we need to do it ourselves, I'll have a look, hopefully this week (very 
possible)

Cheers

Jacques


Le 30/04/2018 à 16:51, Daniel Dekany a écrit :

Seems this was forgotten. Do you plan to do it?


Monday, January 8, 2018, 11:04:31 AM, Jacques Le Roux wrote:


Thanks Daniel,

That's a good news. I did not want to get further with
try.freemarker.org waiting for this to happen. Once LetsEncrypt setting is done 
a redirection
should be enough

Jacques

Le 08/01/2018 à 09:47, Daniel Dekany a écrit :

Greg commented on the request:

try.freemarker.apache.org now works, and is propagated.

Since that hostname maps to your VM, the certificate to be used for
try.freemarker.apache.org will need to be hosted/operated by your VM.
Infra's current policy for project VMs is to use LetsEncrypt for
certificates. [~pono] will get you set up with that.


Wednesday, January 3, 2018, 11:34:32 PM, Jacques Le Roux wrote:


Good, Greg closed INFRA-15476

Jacques

Le 03/01/2018 à 21:23, Daniel Dekany a écrit :

I'm "a bit" late with this, but I have created the issue for it:
https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-15775


Friday, December 15, 2017, 1:57:04 PM, Daniel Dekany wrote:


To summarize, the opininos were (whether we should switch to 
try.freemarker.apache.org):
- Daniel Dekany: We better not risk not doing this
- Jacopo Cappellato: Agrees with me (above) in this
- Jacques Le Roux: No opinion was expressed, but it's technically fine
- Ralph Goers: It's certainly not necessary to do

So, unless someone has more to add, I will ask this from Infra in the
coming days... just to be on the safe side.

Wednesday, November 29, 2017, 6:38:05 PM, Ralph Goers wrote:


The difference is that try.freemarker.org
<http://try.freemarker.org/> is a companion site. So long as the
main site is freemarker.apache.org I don’t think anyone will complain about a 
companion site.

Ralph


On Nov 29, 2017, at 8:33 AM, Jacques Le Roux  
wrote:

Hi Ralph,

IIRW openoffice.org is an exception. There are others, when the domain was well 
established before entering the incubator, subversion.org comes to mind.

IMO freemarker.org was well established before entering the incubator but not 
try.freemarker.apache.org which is quite recent. Hence maybe some caution 
needed...

My 2 cts

Jacques


Le 29/11/2017 à 14:55, Ralph Goers a écrit :

Personally, I don’t see why there should be a problem as long as try.freemarker.org 
<http://try.freemarker.org/> is an Apache controlled domain. You aren’t the only 
project that has a vanity domain. See www.openoffice.org <http://www.openoffice.org/> 
as an example.

Ralph


On Nov 29, 2017, at 1:51 AM, Daniel Dekany  wrote:

Just as a reminder, I'm planning to request try.freemarker.apache.org,
from Infra and then redirect try.freemarker.org to it, because I'm
worried that the IPMC will dislike that we use try.freemarker.org as
the canonical address of the online template tester. It will also use
https and a LetsEncrypt certificate (we can't use the *.apache.org
cert on a VM).

BTW, using a sub-sub domains is a bit extreme. I'm not aware of any
gotchas in out case, but if anyone is aware some, like LetsEncrypt
doesn't support them or something, please stop me! (Also, as this way
we will receive the cookies of freemarker.apache.org, but certainly we
will able to cope with that, if it ever causes a problem.)

Any comments? And do you (especially PPMC members) agree?

--
Thanks,
Daniel Dekany

Re: [ANNOUNCE] Apache FreeMarker 2.3.28 released

2018-04-05 Thread Jacques Le Roux


Excellent, thanks guys for your work!

Jacques


Le 05/04/2018 à 15:22, Woonsan Ko a écrit :

Great news! Congrats!

Woonsan

On Thu, Apr 5, 2018 at 6:20 AM, Jacopo Cappellato
 wrote:

kudos!!!

Jacopo

On Thu, Apr 5, 2018 at 11:01 AM, Daniel Dekany  wrote:


The Apache FreeMarker community is pleased to announce the release of
Apache FreeMarker 2.3.28.

Apache FreeMarker is a template engine: a Java library to generate
text output (HTML web pages, e-mails, configuration files, source
code, etc.) based on templates and changing data. FreeMarker 2.x
produces releases since 2002, and has joined the ASF in 2015.

Change log:
https://freemarker.apache.org/docs/versions_2_3_28.html

You can get binary and source packages from here:
https://freemarker.apache.org/freemarkerdownload.html

Or with Maven:

   
 org.freemarker
 freemarker
 2.3.28

Re: [VOTE] Release Apache FreeMarker 2.3.28

2018-04-01 Thread Jacques Le Roux


Le 01/04/2018 à 07:38, Jacopo Cappellato a écrit :

On Sat, Mar 31, 2018 at 11:06 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Jacopo,

Yes, that's what I have used.


No, your patch is different from mine and this is why it is not able to
fetch the files from the staging Maven repository. Please check the
differences of the line numbers of the first chunks of the patches.

Jacopo


Ho I see now, thanks for the tip!

Jacques

Re: [VOTE] Release Apache FreeMarker 2.3.28

2018-03-31 Thread Jacques Le Roux

Thanks Jacopo,

Yes, that's what I have used. just that I used the complete url:

    url 
"https://repository.apache.org/content/repositories/staging/org/freemarker";

instead. I agree with you and Daniel that using a more generic url is better 
(cover more cases if needed).

Note for myself: I noticed this error when looking into FreeMarkerWorker 
"VERSION_2_3_28 cannot be resolved or is not a field"
"gradlew eclipse" fixed it of course :)

For the pom file in my .m2 local repo I can use a Windows Internet shortcut (which agreeably surprised me). Is the same possible with Linux? Are Linux 
aliases only local?

Jacques

Le 31/03/2018 à 22:38, Jacopo Cappellato a écrit :

  Jacques,

you should be able to test the new release in OFBiz with the following
changes

Jacopo

Index: build.gradle

===

--- build.gradle (revision 1827982)

+++ build.gradle (working copy)

@@ -76,6 +79,9 @@

  repositories{

  jcenter()

  mavenLocal()

+maven {

+url "
https://repository.apache.org/content/repositories/staging/";

+}

  }

  }

@@ -143,7 +149,7 @@

  compile 'org.apache.xmlrpc:xmlrpc-client:3.1.3'

  compile 'org.apache.xmlrpc:xmlrpc-server:3.1.3'

  compile 'org.codehaus.groovy:groovy-all:2.4.13'

-compile 'org.freemarker:freemarker:2.3.27-incubating' // Remember to
change the version number in FreeMarkerWorker class when upgrading

+compile 'org.freemarker:freemarker:2.3.28' // Remember to change the
version number in FreeMarkerWorker class when upgrading

  compile 'org.hamcrest:hamcrest-all:1.3'

  compile 'org.owasp.esapi:esapi:2.1.0.1'

  compile 'org.springframework:spring-test:5.0.2.RELEASE'

On Sat, Mar 31, 2018 at 9:38 PM, Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:

Jacques, tomorrow I will send you the patch.

Jacopo

Il Sab 31 Mar 2018, 20:13 Jacques Le Roux 
ha scritto:

Le 31/03/2018 à 19:42, Daniel Dekany a écrit :

Saturday, March 31, 2018, 5:44:07 PM, Jacques Le Roux wrote:

+1 (binding)

Sha1 and MD5 on freemarker-2.3.28.jar OK.

I think we should drop sha1 with md5 and provide sha256 at least.

For now it's OK with sha1 as Jacopo's link at [1] says.

But we don't provide an sha1. It's an sha512.

At https://repository.apache.org/content/repositories/staging/
org/freemarker/freemarker/2.3.28/
I see only .sha1 suffixes
To check sha in
https://repository.apache.org/content/repositories/staging/
org/freemarker/freemarker/2.3.28/freemarker-2.3.28.jar.sha1 with value
7200064467a935052f99d114c2c05c3d189bc6d6
I used this Windows tool: https://raylin.wordpress.com/
downloads/md5-sha-1-checksum-utility
It reports
  MD5 Checksum: C5E35D814518DA7B0247D42311B8E296
  SHA-1 Checksum: 7200064467A935052F99D114C2C05C3D189BC6D6
  SHA-256 Checksum: DE92D103D3A86C2287307218FF50DC
1C941DE283F7B9E1FB23E93FC7220838BF
  SHA-512 Checksum: 44435CB2B6BA02ABACDC4A21BEA44A
2DC50FAA1B486FC5B2F79097A68F1F98CA24AA835448AC5DEC33A1869EED
1B8A32AC285E95FDABBDAFAA810D575951894E
What could be wrong?

OFBiz trunk HEAD with freemarker-2.3.28 works well (for myself to
remember: putting  pom+jar in my local maven repo and adding
maven {
   url
"https://repository.apache.org/content/repositories/

staging/org/freemarker"

   }
in the main OFBiz build.gradle repositories

You don't need to add the staged artifact(s) to your local repository
manually, because you have added the ASF staging repo to the repos.
Except, your repo URL was wrong, so it did nothing. It should be:
"https://repository.apache.org/content/repositories/staging/";

When I do so I get
C:\projectsASF\ofbiz>gradlew clean ofbiz
FAILURE: Build failed with an exception.

* Where:
Build file 'C:\projectsASF\ofbiz\build.gradle' line: 1031

* What went wrong:
A problem occurred evaluating root project 'ofbiz'.
  > Could not resolve all dependencies for configuration ':runtime'.
 > Could not find org.freemarker:freemarker:2.3.28.
   Searched in the following locations:
https://jcenter.bintray.com/org/freemarker/freemarker/2.3.
28/freemarker-2.3.28.pom
https://jcenter.bintray.com/org/freemarker/freemarker/2.3.
28/freemarker-2.3.28.jar
file:/C:/Users/Jacques/.m2/repository/org/freemarker/
freemarker/2.3.28/freemarker-2.3.28.pom
file:/C:/Users/Jacques/.m2/repository/org/freemarker/
freemarker/2.3.28/freemarker-2.3.28.jar
   Required by:
   project :
 > Could not find org.freemarker:freemarker:2.3.28.
   Searched in the following locations:
https://jcenter.bintray.com/org/freemarker/freemarker/2.3.
28/freemarker-2.3.28.pom
https://jcenter.bintray.com/org/freemarker/freemarker/2.3.
28/freemarker-2.3.28.jar
file:/C:

Re: [VOTE] Release Apache FreeMarker 2.3.28

2018-03-31 Thread Jacques Le Roux


Hi David,

Yes, I know it's not in maven central or jcenter, since it's not yet released.

That's why I did not test using maven central or jcenter, but using my own 
local .m2 repo:

C:\Users\Jacques\.m2\repository\org\freemarker\freemarker\2.3.28

and copying freemarker-2.3.28 pom and jar files there (note: you can even use a 
Windows Internet link for pom, easier)

The other changes I did are in this patch

Index: build.gradle
===
--- build.gradle    (revision 1828108)
+++ build.gradle    (working copy)
@@ -26,7 +26,11 @@
 buildscript {
 repositories {
 jcenter()
-    }
+ maven {
+    url 
"https://repository.apache.org/content/repositories/staging/org/freemarker";
+    }
+}
+
 dependencies {
 classpath 'at.bxm.gradleplugins:gradle-svntools-plugin:latest.release'
 classpath 'org.asciidoctor:asciidoctor-gradle-plugin:1.5.7'
@@ -143,7 +147,7 @@
 compile 'org.apache.xmlrpc:xmlrpc-client:3.1.3'
 compile 'org.apache.xmlrpc:xmlrpc-server:3.1.3'
 compile 'org.codehaus.groovy:groovy-all:2.4.13'
-    compile 'org.freemarker:freemarker:2.3.27-incubating' // Remember to 
change the version number in FreeMarkerWorker class when upgrading
+    compile 'org.freemarker:freemarker:2.3.28' // Remember to change the 
version number in FreeMarkerWorker class when upgrading
 compile 'org.hamcrest:hamcrest-all:1.3'
 compile 'org.owasp.esapi:esapi:2.1.0.1'
 compile 'org.springframework:spring-test:5.0.2.RELEASE'
Index: 
framework/base/src/main/java/org/apache/ofbiz/base/util/template/FreeMarkerWorker.java
===
--- 
framework/base/src/main/java/org/apache/ofbiz/base/util/template/FreeMarkerWorker.java
 (revision 1828108)
+++ 
framework/base/src/main/java/org/apache/ofbiz/base/util/template/FreeMarkerWorker.java
 (working copy)
@@ -70,7 +70,7 @@

 public static final String module = FreeMarkerWorker.class.getName();

-    public static final Version version = Configuration.VERSION_2_3_27;
+    public static final Version version = Configuration.VERSION_2_3_28;

 private FreeMarkerWorker () {}

Jacques


Le 31/03/2018 à 21:57, David E Jones a écrit :

Jacques,

You can't test the pre-release via download from maven central or jcenter,
it isn't there yet. In gradle you have to comment the existing current
version dependency and add a local one which I believe is what Jacopo
mentioned sending a patch for.

This isn't a Freemarker issue or an OFBiz issue, just an issue with your
local modified gradle file trying to point to a dependency that doesn't
exist.

-David



On Sat, Mar 31, 2018 at 12:38 PM, Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:


Jacques, tomorrow I will send you the patch.

Jacopo

Il Sab 31 Mar 2018, 20:13 Jacques Le Roux 
ha
scritto:


Le 31/03/2018 à 19:42, Daniel Dekany a écrit :

Saturday, March 31, 2018, 5:44:07 PM, Jacques Le Roux wrote:


+1 (binding)

Sha1 and MD5 on freemarker-2.3.28.jar OK.

I think we should drop sha1 with md5 and provide sha256 at least.

For now it's OK with sha1 as Jacopo's link at [1] says.

But we don't provide an sha1. It's an sha512.

At
https://repository.apache.org/content/repositories/staging/

org/freemarker/freemarker/2.3.28/

I see only .sha1 suffixes
To check sha in

https://repository.apache.org/content/repositories/staging/

org/freemarker/freemarker/2.3.28/freemarker-2.3.28.jar.sha1

with value
7200064467a935052f99d114c2c05c3d189bc6d6
I used this Windows tool:
https://raylin.wordpress.com/downloads/md5-sha-1-checksum-utility
It reports
  MD5 Checksum: C5E35D814518DA7B0247D42311B8E296
  SHA-1 Checksum: 7200064467A935052F99D114C2C05C3D189BC6D6
  SHA-256 Checksum:
DE92D103D3A86C2287307218FF50DC1C941DE283F7B9E1FB23E93FC7220838BF
  SHA-512 Checksum:
44435CB2B6BA02ABACDC4A21BEA44A2DC50FAA1B486FC5B2F79097A68F1F

98CA24AA835448AC5DEC33A1869EED1B8A32AC285E95FDABBDAFAA810D575951894E

What could be wrong?


OFBiz trunk HEAD with freemarker-2.3.28 works well (for myself to
remember: putting  pom+jar in my local maven repo and adding
maven {
   url
"

https://repository.apache.org/content/repositories/staging/

org/freemarker"

   }
in the main OFBiz build.gradle repositories

You don't need to add the staged artifact(s) to your local repository
manually, because you have added the ASF staging repo to the repos.
Except, your repo URL was wrong, so it did nothing. It should be:
"https://repository.apache.org/content/repositories/staging/";

When I do so I get
C:\projectsASF\ofbiz>gradlew clean ofbiz
FAILURE: Build failed with an exception.

* Where:
Build file 'C:\projectsASF\ofbiz\build.gradle

Re: [VOTE] Release Apache FreeMarker 2.3.28

2018-03-31 Thread Jacques Le Roux


Le 31/03/2018 à 22:42, Daniel Dekany a écrit :

We are talking about two different things. The material linked by
Jacopo talks about the checksums used on dist.apache.org (like
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.28/source/),
not about the Maven repositories.

Also, as far as I see, everybody only has md5 and sha1 in the Maven
repositories. It's generated by Maven itself. I guess that isn't
supposed to protect against fraud...


Ho right, I confused the 2 things. I see the right thing now at
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.28/binaries/apache-freemarker-2.3.28-bin.tar.gz.sha512

Sorry for the noise

Jacques

Re: [VOTE] Release Apache FreeMarker 2.3.28

2018-03-31 Thread Jacques Le Roux

Le 31/03/2018 à 19:42, Daniel Dekany a écrit :

Saturday, March 31, 2018, 5:44:07 PM, Jacques Le Roux wrote:

+1 (binding)

Sha1 and MD5 on freemarker-2.3.28.jar OK.

I think we should drop sha1 with md5 and provide sha256 at least.

For now it's OK with sha1 as Jacopo's link at [1] says.

But we don't provide an sha1. It's an sha512.

At 
https://repository.apache.org/content/repositories/staging/org/freemarker/freemarker/2.3.28/
I see only .sha1 suffixes
To check sha in
https://repository.apache.org/content/repositories/staging/org/freemarker/freemarker/2.3.28/freemarker-2.3.28.jar.sha1 with value 
7200064467a935052f99d114c2c05c3d189bc6d6

I used this Windows tool: 
https://raylin.wordpress.com/downloads/md5-sha-1-checksum-utility
It reports
    MD5 Checksum: C5E35D814518DA7B0247D42311B8E296
    SHA-1 Checksum: 7200064467A935052F99D114C2C05C3D189BC6D6
    SHA-256 Checksum: 
DE92D103D3A86C2287307218FF50DC1C941DE283F7B9E1FB23E93FC7220838BF
    SHA-512 Checksum: 
44435CB2B6BA02ABACDC4A21BEA44A2DC50FAA1B486FC5B2F79097A68F1F98CA24AA835448AC5DEC33A1869EED1B8A32AC285E95FDABBDAFAA810D575951894E
What could be wrong?

OFBiz trunk HEAD with freemarker-2.3.28 works well (for myself to
remember: putting  pom+jar in my local maven repo and adding
   maven {
      url
"https://repository.apache.org/content/repositories/staging/org/freemarker";
      }
in the main OFBiz build.gradle repositories

You don't need to add the staged artifact(s) to your local repository
manually, because you have added the ASF staging repo to the repos.
Except, your repo URL was wrong, so it did nothing. It should be:
"https://repository.apache.org/content/repositories/staging/";

When I do so I get
C:\projectsASF\ofbiz>gradlew clean ofbiz
FAILURE: Build failed with an exception.

* Where:
Build file 'C:\projectsASF\ofbiz\build.gradle' line: 1031

* What went wrong:
A problem occurred evaluating root project 'ofbiz'.
> Could not resolve all dependencies for configuration ':runtime'.
   > Could not find org.freemarker:freemarker:2.3.28.
 Searched in the following locations:
https://jcenter.bintray.com/org/freemarker/freemarker/2.3.28/freemarker-2.3.28.pom
https://jcenter.bintray.com/org/freemarker/freemarker/2.3.28/freemarker-2.3.28.jar
file:/C:/Users/Jacques/.m2/repository/org/freemarker/freemarker/2.3.28/freemarker-2.3.28.pom
file:/C:/Users/Jacques/.m2/repository/org/freemarker/freemarker/2.3.28/freemarker-2.3.28.jar
 Required by:
 project :
   > Could not find org.freemarker:freemarker:2.3.28.
 Searched in the following locations:
https://jcenter.bintray.com/org/freemarker/freemarker/2.3.28/freemarker-2.3.28.pom
https://jcenter.bintray.com/org/freemarker/freemarker/2.3.28/freemarker-2.3.28.jar
file:/C:/Users/Jacques/.m2/repository/org/freemarker/freemarker/2.3.28/freemarker-2.3.28.pom
file:/C:/Users/Jacques/.m2/repository/org/freemarker/freemarker/2.3.28/freemarker-2.3.28.jar
 Required by:
 project : > com.googlecode.ez-vcard:ez-vcard:0.9.10

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.

BUILD FAILED

Total time: 3.623 secs

Could be an OFBiz issue rather...

Jacques

Jacques

Le 31/03/2018 à 10:48, Jacopo Cappellato a écrit :

+1 (binding)

***verifications performed on apache-freemarker-2.3.28-src.tar.gz:
verified successfully sha512
verified successfully md5 (however with the new policy updates this
checksum can be removed in future releases, see [1])
verified successfully the signature
build successful
all unit tests successful

***verifications performed on apache-freemarker-gae-2.3.28-src.tar.gz:
verified successfully sha512
verified successfully md5 (however with the new policy updates this
checksum can be removed in future releases, see [1])
verified successfully the signature
build successful
all unit tests successful

***verifications performed on Maven artifact (freemarker-2.3.28.jar):
tested successfully with Apache OFBiz trunk

Kind regards,

Jacopo Cappellato

[1] http://www.apache.org/dev/release-distribution#sigs-and-sums

On Sat, Mar 31, 2018 at 12:31 AM, Daniel Dekany  wrote:

Hi all,

Please vote on releasing FreeMarker 2.3.28! Note that as this is not
an incubating release anymore, if this vote passes, then the product
will be immediately released (there's no IPMC to review it in a second
round), so check the release carefully! Also please watch out for any
mistakes I make because of differences to releasing from outside the
Incubator for the first time. Thanks!

Note that because there weren't many deep changes since the last
release, we have no Release Candidate this time. Thus, it's important
that you don't skip testing this release with your dependant projects.

Release Notes:
https://freemarker.apache.org/builds/2.3.28-voting/
documentation/versions_2_3_28.htm

Re: [VOTE] Release Apache FreeMarker 2.3.28

2018-03-31 Thread Jacques Le Roux


+1 (binding)

Sha1 and MD5 on freemarker-2.3.28.jar OK.

I think we should drop sha1 with md5 and provide sha256 at least.
For now it's OK with sha1 as Jacopo's link at [1] says.

OFBiz trunk HEAD with freemarker-2.3.28 works well (for myself to remember: 
putting  pom+jar in my local maven repo and adding
 maven {
    url 
"https://repository.apache.org/content/repositories/staging/org/freemarker";
    }
in the main OFBiz build.gradle repositories

Jacques


Le 31/03/2018 à 10:48, Jacopo Cappellato a écrit :

+1 (binding)

***verifications performed on apache-freemarker-2.3.28-src.tar.gz:
verified successfully sha512
verified successfully md5 (however with the new policy updates this
checksum can be removed in future releases, see [1])
verified successfully the signature
build successful
all unit tests successful

***verifications performed on apache-freemarker-gae-2.3.28-src.tar.gz:
verified successfully sha512
verified successfully md5 (however with the new policy updates this
checksum can be removed in future releases, see [1])
verified successfully the signature
build successful
all unit tests successful

***verifications performed on Maven artifact (freemarker-2.3.28.jar):
tested successfully with Apache OFBiz trunk

Kind regards,

Jacopo Cappellato

[1] http://www.apache.org/dev/release-distribution#sigs-and-sums

On Sat, Mar 31, 2018 at 12:31 AM, Daniel Dekany  wrote:


Hi all,

Please vote on releasing FreeMarker 2.3.28! Note that as this is not
an incubating release anymore, if this vote passes, then the product
will be immediately released (there's no IPMC to review it in a second
round), so check the release carefully! Also please watch out for any
mistakes I make because of differences to releasing from outside the
Incubator for the first time. Thanks!

Note that because there weren't many deep changes since the last
release, we have no Release Candidate this time. Thus, it's important
that you don't skip testing this release with your dependant projects.

Release Notes:
https://freemarker.apache.org/builds/2.3.28-voting/
documentation/versions_2_3_28.html

Before proceed, you should know that FreeMarker 2.3.x, for a long
time, always releases a normal and a "gae" variant on the same time,
which are technically two independent source trees (Git branches). The
"gae" variant contains a few small modification in the Java source
code to be Google App Engine compliant, and has freemarker-gae as the
Maven artifact name. Otherwise the normal and the "gae" branches are
identical. Hence they will be voted on together.

The commits to be voted upon are:
- Normal (non-gae) variant:
   https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=
8ee391d10e0256d57a326d83dd487639ccd9659c
   Commit hash: 8ee391d10e0256d57a326d83dd487639ccd9659c
- "gae" variant:
   https://git-wip-us.apache.org/repos/asf?p=freemarker.git;a=commit;h=
8c8fb4c02d63141bd2cee9630cc27a9340d0f94c
   Commit hash: 8c8fb4c02d63141bd2cee9630cc27a9340d0f94c

The artifacts to be voted upon are located here:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.28/source/
where the source release artifacts are:
- Normal (non-gae) variant:
   apache-freemarker-2.3.28-src.tar.gz
- "gae" variant:
   apache-freemarker-gae-2.3.28-src.tar.gz

See the README.md inside them for build instructions!

The release artifacts are signed with the following key:
https://people.apache.org/keys/committer/ddekany.asc

For convenience, we also provide binaries, which also need to be checked:
https://dist.apache.org/repos/dist/dev/freemarker/engine/2.3.28/binaries/
and Maven artifacts in the ASF staging repository:
https://repository.apache.org/content/repositories/staging/
org/freemarker/freemarker/2.3.28/

Please try out the package and vote!

The vote is open for a minimum of 72 hours or until the necessary number of
votes (3 binding +1s) is reached.

[ ] +1 Release this package as Apache FreeMarker 2.3.28
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...

Please add "(binding)" if your vote is binding.

--
Thanks,
  Daniel Dekany

81 matches

Mail list logo