search

DPascalBernard / maven-alfresco-archetypes

Automatically exported from code.google.com/p/maven-alfresco-archetypes
0 stars 0 forks source link

FTL contents are destroyed: module title appears at strange places! #7

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. create folder-properties.get.json.ftl and put it into
src\main\resources\alfresco\extension\templates\webscripts\ of a module

folder-properties.get.json.ftl contains:
[
<#list result as res>
  {"name": "${res.name}", "title": "${res.title}", "text":"${res.text}",
"allowedValues" : [
  <#list res.allowedValues as av>
    "${av}"
    <#if av_has_next>,</#if>
  </#list>
  ]}
  <#if res_has_next>,</#if>
</#list>
]

Wrong result:
[
<#list result as res>
  {"name": "Maven Alfresco AMP Packaging Sample", "title": "${res.title}",
"text":"${res.text}", "allowedValues" : [
  <#list res.allowedValues as av>
    "${av}"
    <#if av_has_next>,</#if>
  </#list>
  ]}
  <#if res_has_next>,</#if>
</#list>
]

Original issue reported on code.google.com by romanno...@gmx.at on 26 Jul 2008 at 5:04

GoogleCodeExporter commented 9 years ago 
following workaround helps:
using ${res.name } works. Freemarker can use it that way. Maven(?: or is there a
custom Mojo involved) doesn't replace it after adding a <SPACE>.

Original comment by romanno...@gmx.at on 26 Jul 2008 at 9:23

GoogleCodeExporter commented 9 years ago 
IIRC this can be easily fixed by removing FTL from build time filtering, which 
as
reported tries to filter on non complete properties.

It's a regression as actually the fix should have been already in the 1.0.0 
version. 

Adding the following snippet to the generated POM should be enough:

<resource>
    <directory>src/main/resources</directory>
    <includes>
        <include>**/*.ftl</include>
    </includes>
    <filtering>false</filtering>
</resource>

Original comment by colum...@gmail.com on 28 Jul 2008 at 7:29

GoogleCodeExporter commented 9 years ago 
Thanks for the info! I had to add also an  
<exclude>**/*.ftl</exclude>
section to the existing src/main/resources section(s. below).

So it looked like this:
    <resource>
    <filtering>false</filtering>
    <directory>src/main/resources</directory>
    <includes>
        <include>**/*.ftl</include>
    </includes>
      </resource>
      <resource>
     <filtering>true</filtering>
     <directory>src/main/resources</directory>
     <excludes>
       <exclude>**README-*</exclude>
       <exclude>**/*.ftl</exclude>
       </excludes>
     </resource>

Please close ticket (i seemingly can't).

Original comment by romanno...@gmx.at on 28 Jul 2008 at 2:30

GoogleCodeExporter commented 9 years ago

Original comment by colum...@gmail.com on 5 Aug 2008 at 2:54

GoogleCodeExporter commented 9 years ago

Original comment by colum...@gmail.com on 5 Aug 2008 at 2:59

GoogleCodeExporter commented 9 years ago

Original comment by colum...@gmail.com on 5 Aug 2008 at 2:59

GoogleCodeExporter commented 9 years ago 
Requires adding:

<nonFilteredFileExtensions>
<nonFilteredFileExtension>
ftl
</nnFilteredFileExtension>
</nnFilteredFileExtensions>

in the archetype. Easy fix for 3.0.0 versions.

Original comment by colum...@gmail.com on 19 Feb 2009 at 2:02

GoogleCodeExporter commented 9 years ago 
Any progress here? Is this bug still present?

Original comment by carlo.sciolla on 27 Feb 2010 at 7:47

GoogleCodeExporter commented 9 years ago 
News? :)

Original comment by colum...@gmail.com on 4 Aug 2011 at 1:34

GoogleCodeExporter commented 9 years ago 
That very FTL retains those placeholders (at least, building using maven3). 
Indeed, name clashing is always awaiting to bite you here, as any valid maven 
property will be substituted (tested with ${project.name}).

I would just update the POMs and by default skip filtering on FTLs as 
suggested, since the same syntax for variable substitution is too sneaky. @Gab: 
your call :-)

Original comment by carlo.sciolla on 5 Aug 2011 at 8:20

GoogleCodeExporter commented 9 years ago 
Fixed for all archetypes at r386.

Requires testing as:

1. Generate project for each archetype
2. Add an FTL in src/main/resources containing ${res.name}
3. Verify that in target/classes that FTL is not replaced

Original comment by colum...@gmail.com on 6 Apr 2012 at 11:07

GoogleCodeExporter commented 9 years ago 
Tested, works as expected

Original comment by mauri...@session.it on 6 Apr 2012 at 12:28

GoogleCodeExporter commented 9 years ago

Original comment by mauri...@session.it on 6 Apr 2012 at 6:26