[jira] [Created] (MNG-8068) Add Sentry Maven Skin to the list of available skins for Maven Site plugin
Bertrand Martin created MNG-8068: Summary: Add Sentry Maven Skin to the list of available skins for Maven Site plugin Key: MNG-8068 URL: https://issues.apache.org/jira/browse/MNG-8068 Project: Maven Issue Type: Improvement Components: Sites & Reporting Reporter: Bertrand Martin h1. Requested improvement Add [Sentry Maven Skin|https://sentrysoftware.org/sentry-maven-skin/] in the list of available skins for the Maven Site plugin (outside the Maven world). h1. Specifications Update `content/apt/skins/index.apt` to list this new skin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSITE-869) Options to preprocess site sources and resources through Maven filtering
[
https://issues.apache.org/jira/browse/MSITE-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683502#comment-17683502
]
Bertrand Martin commented on MSITE-869:
---
Okay then, I guess that works!
A sample {{pom.xml}} could be provided as an example, to explain to users how
to achieve that easily. I would even advise to add {{resources:resources}} to
the default lifecycle for {{site}} (although it requires a specific
configuration to filter files from {{src/site}} to {{target/generated-site}})
> Options to preprocess site sources and resources through Maven filtering
>
>
> Key: MSITE-869
> URL: https://issues.apache.org/jira/browse/MSITE-869
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: property interpolation
>Reporter: Bertrand Martin
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> h1. Use Case
> User has source files or resources files where Maven properties like
> ${project.version} or ${project.name} need to be replaced with their actual
> value.
> Examples:
> * a [REST API specification|https://swagger.io/specification/] in
> *src/site/resource/openapi.yaml*
> * the title of a Markdown document describing the project (like [Maven Site
> Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
> documentation)
> h1. Workaround
> Usually, [it is recommended to add the .vm
> suffix|https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin]
> to the files that need filtering, so that they are processed as a Velocity
> template.
> But this workaround has several drawbacks:
> * [Velocity and Markdown formats are highly
> incompatible|https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm]
> because of the headings format
> * Velocity has 1000 times more features than just filtering, which is great,
> but also which can unexpectedly conflict with source files and with resource
> files (which may be from external sources, like JS libraries, YAML, etc.)
> * .vm files are handled as Velocity templates in most code editors (VSCode,
> etc.), which prevents any other advanced features from working (especially on
> openapi.yaml, where you can have linting, validation, autosuggest, etc.)
> Basically, Velocity templates is a great feature that needs to stay, but it's
> overkill for just replacing ${project.version} in a bunch of files.
> h1. Specifications
> Add options to filter site source files and resource files:
> * {{boolean sourceFiltering}} (default: false)
> * {{boolean resourceFiltering}} (default: false)
> * {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp,
> png)
> * {{boolean fileNameFiltering}} (default: false)
> Use Maven's filtering component:
> {code:java}
> @Component(role = MavenResourcesFiltering.class, hint = "default")
> private MavenResourcesFiltering mavenResourcesFiltering;
> {code}
> .vm files don't need to be filtered. There are therefore 3 cases:
> * no filtering
> * simple filtering (like [Maven Resource
> Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
> * advanced templating
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-869) Options to preprocess site sources and resources through Maven filtering
[
https://issues.apache.org/jira/browse/MSITE-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683480#comment-17683480
]
Bertrand Martin commented on MSITE-869:
---
Would that apply to `site.xml` as well?
> Options to preprocess site sources and resources through Maven filtering
>
>
> Key: MSITE-869
> URL: https://issues.apache.org/jira/browse/MSITE-869
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: property interpolation
>Reporter: Bertrand Martin
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> h1. Use Case
> User has source files or resources files where Maven properties like
> ${project.version} or ${project.name} need to be replaced with their actual
> value.
> Examples:
> * a [REST API specification|https://swagger.io/specification/] in
> *src/site/resource/openapi.yaml*
> * the title of a Markdown document describing the project (like [Maven Site
> Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
> documentation)
> h1. Workaround
> Usually, [it is recommended to add the .vm
> suffix|https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin]
> to the files that need filtering, so that they are processed as a Velocity
> template.
> But this workaround has several drawbacks:
> * [Velocity and Markdown formats are highly
> incompatible|https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm]
> because of the headings format
> * Velocity has 1000 times more features than just filtering, which is great,
> but also which can unexpectedly conflict with source files and with resource
> files (which may be from external sources, like JS libraries, YAML, etc.)
> * .vm files are handled as Velocity templates in most code editors (VSCode,
> etc.), which prevents any other advanced features from working (especially on
> openapi.yaml, where you can have linting, validation, autosuggest, etc.)
> Basically, Velocity templates is a great feature that needs to stay, but it's
> overkill for just replacing ${project.version} in a bunch of files.
> h1. Specifications
> Add options to filter site source files and resource files:
> * {{boolean sourceFiltering}} (default: false)
> * {{boolean resourceFiltering}} (default: false)
> * {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp,
> png)
> * {{boolean fileNameFiltering}} (default: false)
> Use Maven's filtering component:
> {code:java}
> @Component(role = MavenResourcesFiltering.class, hint = "default")
> private MavenResourcesFiltering mavenResourcesFiltering;
> {code}
> .vm files don't need to be filtered. There are therefore 3 cases:
> * no filtering
> * simple filtering (like [Maven Resource
> Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
> * advanced templating
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MSITE-869) Options to preprocess site sources and resources through Maven filtering
[
https://issues.apache.org/jira/browse/MSITE-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683480#comment-17683480
]
Bertrand Martin edited comment on MSITE-869 at 2/2/23 4:27 PM:
---
Would that apply to {{site.xml}} as well?
was (Author: bertrandmartin):
Would that apply to `site.xml` as well?
> Options to preprocess site sources and resources through Maven filtering
>
>
> Key: MSITE-869
> URL: https://issues.apache.org/jira/browse/MSITE-869
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: property interpolation
>Reporter: Bertrand Martin
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> h1. Use Case
> User has source files or resources files where Maven properties like
> ${project.version} or ${project.name} need to be replaced with their actual
> value.
> Examples:
> * a [REST API specification|https://swagger.io/specification/] in
> *src/site/resource/openapi.yaml*
> * the title of a Markdown document describing the project (like [Maven Site
> Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
> documentation)
> h1. Workaround
> Usually, [it is recommended to add the .vm
> suffix|https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin]
> to the files that need filtering, so that they are processed as a Velocity
> template.
> But this workaround has several drawbacks:
> * [Velocity and Markdown formats are highly
> incompatible|https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm]
> because of the headings format
> * Velocity has 1000 times more features than just filtering, which is great,
> but also which can unexpectedly conflict with source files and with resource
> files (which may be from external sources, like JS libraries, YAML, etc.)
> * .vm files are handled as Velocity templates in most code editors (VSCode,
> etc.), which prevents any other advanced features from working (especially on
> openapi.yaml, where you can have linting, validation, autosuggest, etc.)
> Basically, Velocity templates is a great feature that needs to stay, but it's
> overkill for just replacing ${project.version} in a bunch of files.
> h1. Specifications
> Add options to filter site source files and resource files:
> * {{boolean sourceFiltering}} (default: false)
> * {{boolean resourceFiltering}} (default: false)
> * {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp,
> png)
> * {{boolean fileNameFiltering}} (default: false)
> Use Maven's filtering component:
> {code:java}
> @Component(role = MavenResourcesFiltering.class, hint = "default")
> private MavenResourcesFiltering mavenResourcesFiltering;
> {code}
> .vm files don't need to be filtered. There are therefore 3 cases:
> * no filtering
> * simple filtering (like [Maven Resource
> Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
> * advanced templating
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-869) Options to preprocess site sources and resources through Maven filtering
[
https://issues.apache.org/jira/browse/MSITE-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683178#comment-17683178
]
Bertrand Martin commented on MSITE-869:
---
I'm sorry but I don't see how this could solve the problem entirely. Are you
suggesting invoking the *maven-resource-plugin* in the `pre-site` or
`post-site` phase?
> Options to preprocess site sources and resources through Maven filtering
>
>
> Key: MSITE-869
> URL: https://issues.apache.org/jira/browse/MSITE-869
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: property interpolation
>Reporter: Bertrand Martin
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> h1. Use Case
> User has source files or resources files where Maven properties like
> ${project.version} or ${project.name} need to be replaced with their actual
> value.
> Examples:
> * a [REST API specification|https://swagger.io/specification/] in
> *src/site/resource/openapi.yaml*
> * the title of a Markdown document describing the project (like [Maven Site
> Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
> documentation)
> h1. Workaround
> Usually, [it is recommended to add the .vm
> suffix|https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin]
> to the files that need filtering, so that they are processed as a Velocity
> template.
> But this workaround has several drawbacks:
> * [Velocity and Markdown formats are highly
> incompatible|https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm]
> because of the headings format
> * Velocity has 1000 times more features than just filtering, which is great,
> but also which can unexpectedly conflict with source files and with resource
> files (which may be from external sources, like JS libraries, YAML, etc.)
> * .vm files are handled as Velocity templates in most code editors (VSCode,
> etc.), which prevents any other advanced features from working (especially on
> openapi.yaml, where you can have linting, validation, autosuggest, etc.)
> Basically, Velocity templates is a great feature that needs to stay, but it's
> overkill for just replacing ${project.version} in a bunch of files.
> h1. Specifications
> Add options to filter site source files and resource files:
> * {{boolean sourceFiltering}} (default: false)
> * {{boolean resourceFiltering}} (default: false)
> * {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp,
> png)
> * {{boolean fileNameFiltering}} (default: false)
> Use Maven's filtering component:
> {code:java}
> @Component(role = MavenResourcesFiltering.class, hint = "default")
> private MavenResourcesFiltering mavenResourcesFiltering;
> {code}
> .vm files don't need to be filtered. There are therefore 3 cases:
> * no filtering
> * simple filtering (like [Maven Resource
> Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
> * advanced templating
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-869) Options to preprocess site sources and resources through Maven filtering
[
https://issues.apache.org/jira/browse/MSITE-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683067#comment-17683067
]
Bertrand Martin commented on MSITE-869:
---
Yes, but I think MSITE-869 is better explained and specified than DOXIA-677 😁
> Options to preprocess site sources and resources through Maven filtering
>
>
> Key: MSITE-869
> URL: https://issues.apache.org/jira/browse/MSITE-869
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: property interpolation
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> User has source files or resources files where Maven properties like
> ${project.version} or ${project.name} need to be replaced with their actual
> value.
> Examples:
> * a [REST API specification|https://swagger.io/specification/] in
> *src/site/resource/openapi.yaml*
> * the title of a Markdown document describing the project (like [Maven Site
> Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
> documentation)
> h1. Workaround
> Usually, [it is recommended to add the .vm
> suffix|https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin]
> to the files that need filtering, so that they are processed as a Velocity
> template.
> But this workaround has several drawbacks:
> * [Velocity and Markdown formats are highly
> incompatible|https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm]
> because of the headings format
> * Velocity has 1000 times more features than just filtering, which is great,
> but also which can unexpectedly conflict with source files and with resource
> files (which may be from external sources, like JS libraries, YAML, etc.)
> * .vm files are handled as Velocity templates in most code editors (VSCode,
> etc.), which prevents any other advanced features from working (especially on
> openapi.yaml, where you can have linting, validation, autosuggest, etc.)
> Basically, Velocity templates is a great feature that needs to stay, but it's
> overkill for just replacing ${project.version} in a bunch of files.
> h1. Specifications
> Add options to filter site source files and resource files:
> * {{boolean sourceFiltering}} (default: false)
> * {{boolean resourceFiltering}} (default: false)
> * {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp,
> png)
> * {{boolean fileNameFiltering}} (default: false)
> Use Maven's filtering component:
> {code:java}
> @Component(role = MavenResourcesFiltering.class, hint = "default")
> private MavenResourcesFiltering mavenResourcesFiltering;
> {code}
> .vm files don't need to be filtered. There are therefore 3 cases:
> * no filtering
> * simple filtering (like [Maven Resource
> Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
> * advanced templating
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650801#comment-17650801
]
Bertrand Martin edited comment on DOXIA-617 at 12/21/22 10:15 AM:
--
Thank you [~hboutemy], this clarifies the workflow, which has an extra step for
Markdown, since it goes through the _XhtmlParser_, that's what I meant (as
documented in your beautiful diagram ;-) )
was (Author: bertrandmartin):
Thank you [~hboutemy], this clarifies the workflow, which has an extra step for
Markdown, since it goes through the *XhtmlParser*, that's what I meant (as
documented in your beautiful diagram ;-) )
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650801#comment-17650801
]
Bertrand Martin commented on DOXIA-617:
---
Thank you [~hboutemy], this clarifies the workflow, which has an extra step for
Markdown, since it goes through the *XhtmlParser*, that's what I meant (as
documented in your beautiful diagram ;-) )
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650027#comment-17650027
]
Bertrand Martin edited comment on DOXIA-617 at 12/21/22 12:15 AM:
--
Good point. So {{author}}, {{description}} and {{date}} would need a special
treatment, like {{title}}?
Where I'm confused is that the Markdown parser generates an HTML output (with
the {{}} and {{}} tags in the header) and doesn't use any specific
Sink methods. So we shouldn't need to worry about {{author}}, {{description}}
and {{date}}.
Just to make sure I understand properly the data flow, do you confirm it's:
# Markdown parser transforms Markdown source into HTML
# Xhtml parser then transform this HTML into a Doxia document, using the *Sink*
# Maven Site plugin uses the XhtmlSink to produce the HTML page
# This HTML page is then processed by the Skin to produce the final document
Or are points 2 and 3 skipped? Or I missed something? 😅
was (Author: bertrandmartin):
Good point. So {{author}}, {{description}} and {{date}} will need a special
treatment, like {{title}}.
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650027#comment-17650027
]
Bertrand Martin commented on DOXIA-617:
---
Good point. So {{author}}, {{description}} and {{date}} will need a special
treatment, like {{title}}.
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649512#comment-17649512
]
Bertrand Martin commented on DOXIA-617:
---
What do you mean? What kind of explicit parsing?
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649206#comment-17649206
]
Bertrand Martin edited comment on DOXIA-617 at 12/19/22 8:21 AM:
-
Yes, headers are currently supported. They are added to the {{}} section
of the produced HTML as a {{}}.
One header item is processed differently though: {{title}} which is rendered
with the {{}} tag.
Example:
{code}
title: An Example of a Markdown File
description: Example of a Markdown file properly processed with a mix of Doxia,
Flexmark and Maven Site Plugin
keywords: markdown,flexmark,maven,doxia,site,header
## My heading
Some content
{code}
This will be rendered as:
{code:html}
An Example of a Markdown File
My heading
Some content
{code}
Note that with the YAML Front Matter extension, the new syntax for specifying
headers will become:
{code}
title: An Example of a Markdown File
description: Example of a Markdown file properly processed with a mix of Doxia,
Flexmark and Maven Site Plugin
keywords: markdown,flexmark,maven,doxia,site,header
---
## My heading
Some content
{code}
Ideally, both syntaxes would be allowed, as some projects do use Markdown
headers with Doxia (all of my company's documentation is written this way!).
It would be done by "simply" inserting the {{---}} mark where it's supposed to
be... if it's not already present.
I trust you'll make this happen! 😊
was (Author: bertrandmartin):
Yes, headers are currently supported. They are added to the {{}} section
of the produced HTML as a {{}}.
One header item is processed differently though: {{title}} which is rendered
with the {{}} tag.
Example:
{code:markdown}
title: An Example of a Markdown File
description: Example of a Markdown file properly processed with a mix of Doxia,
Flexmark and Maven Site Plugin
keywords: markdown,flexmark,maven,doxia,site,header
## My heading
Some content
{code}
This will be rendered as:
{code:html}
An Example of a Markdown File
My heading
Some content
{code}
Note that with the YAML Front Matter extension, the new syntax for specifying
headers will become:
{code:markdown}
title: An Example of a Markdown File
description: Example of a Markdown file properly processed with a mix of Doxia,
Flexmark and Maven Site Plugin
keywords: markdown,flexmark,maven,doxia,site,header
---
## My heading
Some content
{code}
Ideally, both syntaxes would be allowed, as some projects do use Markdown
headers with Doxia (all of my company's documentation is written this way!).
It would be done by "simply" inserting the {{---}} mark where it's supposed to
be... if it's not already present.
I trust you'll make this happen! 😊
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649206#comment-17649206
]
Bertrand Martin commented on DOXIA-617:
---
Yes, headers are currently supported. They are added to the {{}} section
of the produced HTML as a {{}}.
One header item is processed differently though: {{title}} which is rendered
with the {{}} tag.
Example:
{code:markdown}
title: An Example of a Markdown File
description: Example of a Markdown file properly processed with a mix of Doxia,
Flexmark and Maven Site Plugin
keywords: markdown,flexmark,maven,doxia,site,header
## My heading
Some content
{code}
This will be rendered as:
{code:html}
An Example of a Markdown File
My heading
Some content
{code}
Note that with the YAML Front Matter extension, the new syntax for specifying
headers will become:
{code:markdown}
title: An Example of a Markdown File
description: Example of a Markdown file properly processed with a mix of Doxia,
Flexmark and Maven Site Plugin
keywords: markdown,flexmark,maven,doxia,site,header
---
## My heading
Some content
{code}
Ideally, both syntaxes would be allowed, as some projects do use Markdown
headers with Doxia (all of my company's documentation is written this way!).
It would be done by "simply" inserting the {{---}} mark where it's supposed to
be... if it's not already present.
I trust you'll make this happen! 😊
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614986#comment-17614986
]
Bertrand Martin commented on DOXIA-617:
---
I understand your point, and I agree with you. But this change and this header
feature must be documented somewhere in Doxia. It's a pretty cool feature and
it shouldn't be hidden in the code 😉
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573492#comment-17573492
]
Bertrand Martin commented on DOXIA-617:
---
So, no, the YAML header parsing is not enabled. The trickiest part will be the
backward compatibility with the "old" syntax (without the {{---}} dashes). If
we could manage to remove the code that currently handles the header section,
that would be awesome. We would detect the old syntax header, and we would
surround it with dashes so that it's handled automatically with Flexmark's YAML
parser.
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573487#comment-17573487
]
Bertrand Martin commented on DOXIA-617:
---
[~michael-o] I don't know, did you enable the YAML Front Matter Extension of
Flexmark?
If so, is there a build somewhere that we can test?
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIA-619) Sink.sectionTitle1() creates instead of
Bertrand Martin created DOXIA-619:
-
Summary: Sink.sectionTitle1() creates instead of
Key: DOXIA-619
URL: https://issues.apache.org/jira/browse/DOXIA-619
Project: Maven Doxia
Issue Type: Bug
Components: Module - Xhtml, Sink API
Reporter: Bertrand Martin
h1. Problem
The below code in a Maven Report plugin:
{code:java}
Sink mainSink = getSink();
mainSink.section1();
mainSink.sectionTitle1();
mainSink.text("Release Notes");
mainSink.sectionTitle1_();
{code}
produces this HTML:
{code:html}
Release Notes
{code}
Expected HTML was {{}} instead of {{}}:
{code:html}
Release Notes
{code}
As a consequence, documents produced using the *Sink* API in a Maven Report
plugin do not have any {{}} headings and start directly with {{}},
which is not recommended for SEO, and most importantly [for
accessibility|https://www.w3.org/WAI/tutorials/page-structure/headings/].
h1. Specification
Fix the mapping of section levels to HTML heading levels in _Xhtml5BaseSink_
and _XhtmlBaseSink_ (see {{protected void onSectionTitle( int depth,
SinkEventAttributes attributes )}}).
Similarly (and this is riskier), update _baseStartTag()_ and _baseEndTag()_
methods in _Xhtml5BaseParser_ and _XhtmlBaseParser_ classes.
h1. Doc
N/A
h1. Tests
Add corresponding unit and integration tests. This should not break
*maven-site-plugin*'s own integration tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSITE-869) Options to preprocess site sources and resources through Maven filtering
[
https://issues.apache.org/jira/browse/MSITE-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Martin updated MSITE-869:
--
Description:
h1. Use Case
User has source files or resources files where Maven properties like
${project.version} or ${project.name} need to be replaced with their actual
value.
Examples:
* a [REST API specification|https://swagger.io/specification/] in
*src/site/resource/openapi.yaml*
* the title of a Markdown document describing the project (like [Maven Site
Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
documentation)
h1. Workaround
Usually, [it is recommended to add the .vm
suffix|https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin]
to the files that need filtering, so that they are processed as a Velocity
template.
But this workaround has several drawbacks:
* [Velocity and Markdown formats are highly
incompatible|https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm]
because of the headings format
* Velocity has 1000 times more features than just filtering, which is great,
but also which can unexpectedly conflict with source files and with resource
files (which may be from external sources, like JS libraries, YAML, etc.)
* .vm files are handled as Velocity templates in most code editors (VSCode,
etc.), which prevents any other advanced features from working (especially on
openapi.yaml, where you can have linting, validation, autosuggest, etc.)
Basically, Velocity templates is a great feature that needs to stay, but it's
overkill for just replacing ${project.version} in a bunch of files.
h1. Specifications
Add options to filter site source files and resource files:
* {{boolean sourceFiltering}} (default: false)
* {{boolean resourceFiltering}} (default: false)
* {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp, png)
* {{boolean fileNameFiltering}} (default: false)
Use Maven's filtering component:
{code:java}
@Component(role = MavenResourcesFiltering.class, hint = "default")
private MavenResourcesFiltering mavenResourcesFiltering;
{code}
.vm files don't need to be filtered. There are therefore 3 cases:
* no filtering
* simple filtering (like [Maven Resource
Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
* advanced templating
was:
h1. Use Case
User has source files or resources files where Maven properties like
${project.version} or ${project.name} need to be replaced with their actual
value.
Examples:
* a [REST API specification|https://swagger.io/specification/] in
*src/site/resource/openapi.yaml*
* the title of a Markdown document describing the project (like [Maven Site
Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
documentation)
h1. Workaround
Usually, [it is recommended to add the .vm
suffix|https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin]
to the files that need filtering, so that they are processed as a Velocity
template.
But this workaround has several drawbacks:
*
[https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm|Velocity
and Markdown formats are highly incompatible] because of the headings format
* Velocity has 1000 times more features than just filtering, which is great,
but also which can conflict with source files when not expected by the doc
writer, and with resource files (which may be from external sources, like JS
libraries, YAML, etc.)
* .vm files are handled as Velocity templates in most code editors (VSCode,
etc.), which prevents any other advanced features from working (especially on
openapi.yaml, where you can have linting, validation, autosuggest, etc.)
Basically, Velocity templates is a great feature that needs to stay, but it's
overkill for just replacing ${project.version} in a bunch of files.
h1. Specifications
Add options to filter site source files and resource files:
* {{boolean sourceFiltering}} (default: false)
* {{boolean resourceFiltering}} (default: false)
* {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp, png)
* {{boolean fileNameFiltering}} (default: false)
Use Maven's filtering component:
{code:java}
@Component(role = MavenResourcesFiltering.class, hint = "default")
private MavenResourcesFiltering mavenResourcesFiltering;
{code}
.vm files don't need to be filtered. There are therefore 3 cases:
* no filtering
* simple filtering (like [Maven Resource
Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
* advanced templating
> Options to preprocess site sources and resources through Maven filtering
> ---
[jira] [Updated] (MSITE-869) Options to preprocess site sources and resources through Maven filtering
[
https://issues.apache.org/jira/browse/MSITE-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Martin updated MSITE-869:
--
Description:
h1. Use Case
User has source files or resources files where Maven properties like
${project.version} or ${project.name} need to be replaced with their actual
value.
Examples:
* a [REST API specification|https://swagger.io/specification/] in
*src/site/resource/openapi.yaml*
* the title of a Markdown document describing the project (like [Maven Site
Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
documentation)
h1. Workaround
Usually, [it is recommended to add the .vm
suffix|https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin]
to the files that need filtering, so that they are processed as a Velocity
template.
But this workaround has several drawbacks:
*
[https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm|Velocity
and Markdown formats are highly incompatible] because of the headings format
* Velocity has 1000 times more features than just filtering, which is great,
but also which can conflict with source files when not expected by the doc
writer, and with resource files (which may be from external sources, like JS
libraries, YAML, etc.)
* .vm files are handled as Velocity templates in most code editors (VSCode,
etc.), which prevents any other advanced features from working (especially on
openapi.yaml, where you can have linting, validation, autosuggest, etc.)
Basically, Velocity templates is a great feature that needs to stay, but it's
overkill for just replacing ${project.version} in a bunch of files.
h1. Specifications
Add options to filter site source files and resource files:
* {{boolean sourceFiltering}} (default: false)
* {{boolean resourceFiltering}} (default: false)
* {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp, png)
* {{boolean fileNameFiltering}} (default: false)
Use Maven's filtering component:
{code:java}
@Component(role = MavenResourcesFiltering.class, hint = "default")
private MavenResourcesFiltering mavenResourcesFiltering;
{code}
.vm files don't need to be filtered. There are therefore 3 cases:
* no filtering
* simple filtering (like [Maven Resource
Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
* advanced templating
was:
h1. Use Case
User has source files or resources files where Maven properties like
${project.version} or ${project.name} need to be replaced with their actual
value.
Examples:
* a [REST API specification|https://swagger.io/specification/] in
*src/site/resource/openapi.yaml*
* the title of a Markdown document describing the project (like [Maven Site
Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
documentation)
h1. Workaround
Usually,
[https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin|it
is recommended to add the .vm suffix] to the files that need filtering, so
that they are processed as a Velocity template.
But this workaround has several drawbacks:
*
[https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm|Velocity
and Markdown formats are highly incompatible] because of the headings format
* Velocity has 1000 times more features than just filtering, which is great,
but also which can conflict with source files when not expected by the doc
writer, and with resource files (which may be from external sources, like JS
libraries, YAML, etc.)
* .vm files are handled as Velocity templates in most code editors (VSCode,
etc.), which prevents any other advanced features from working (especially on
openapi.yaml, where you can have linting, validation, autosuggest, etc.)
Basically, Velocity templates is a great feature that needs to stay, but it's
overkill for just replacing ${project.version} in a bunch of files.
h1. Specifications
Add options to filter site source files and resource files:
* {{boolean sourceFiltering}} (default: false)
* {{boolean resourceFiltering}} (default: false)
* {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp, png)
* {{boolean fileNameFiltering}} (default: false)
Use Maven's filtering component:
{code:java}
@Component(role = MavenResourcesFiltering.class, hint = "default")
private MavenResourcesFiltering mavenResourcesFiltering;
{code}
.vm files don't need to be filtered. There are therefore 3 cases:
* no filtering
* simple filtering (like [Maven Resource
Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
* advanced templating
> Options to preprocess site sources and resources through Maven filtering
> --
[jira] [Created] (MSITE-869) Options to preprocess site sources and resources through Maven filtering
Bertrand Martin created MSITE-869:
-
Summary: Options to preprocess site sources and resources through
Maven filtering
Key: MSITE-869
URL: https://issues.apache.org/jira/browse/MSITE-869
Project: Maven Site Plugin
Issue Type: Improvement
Components: property interpolation
Reporter: Bertrand Martin
h1. Use Case
User has source files or resources files where Maven properties like
${project.version} or ${project.name} need to be replaced with their actual
value.
Examples:
* a [REST API specification|https://swagger.io/specification/] in
*src/site/resource/openapi.yaml*
* the title of a Markdown document describing the project (like [Maven Site
Plugin|https://maven.apache.org/plugins/maven-site-plugin/index.html]'s own
documentation)
h1. Workaround
Usually,
[https://stackoverflow.com/questions/7111000/resource-filtering-with-maven-site-plugin|it
is recommended to add the .vm suffix] to the files that need filtering, so
that they are processed as a Velocity template.
But this workaround has several drawbacks:
*
[https://github.com/apache/maven-archetypes/blob/master/maven-archetype-plugin-site/src/main/resources/archetype-resources/src/site/markdown/markdown-velocity.md.vm|Velocity
and Markdown formats are highly incompatible] because of the headings format
* Velocity has 1000 times more features than just filtering, which is great,
but also which can conflict with source files when not expected by the doc
writer, and with resource files (which may be from external sources, like JS
libraries, YAML, etc.)
* .vm files are handled as Velocity templates in most code editors (VSCode,
etc.), which prevents any other advanced features from working (especially on
openapi.yaml, where you can have linting, validation, autosuggest, etc.)
Basically, Velocity templates is a great feature that needs to stay, but it's
overkill for just replacing ${project.version} in a bunch of files.
h1. Specifications
Add options to filter site source files and resource files:
* {{boolean sourceFiltering}} (default: false)
* {{boolean resourceFiltering}} (default: false)
* {{List nonFilteredFileExtensions}} (default: jpg, jpeg, gif, bmp, png)
* {{boolean fileNameFiltering}} (default: false)
Use Maven's filtering component:
{code:java}
@Component(role = MavenResourcesFiltering.class, hint = "default")
private MavenResourcesFiltering mavenResourcesFiltering;
{code}
.vm files don't need to be filtered. There are therefore 3 cases:
* no filtering
* simple filtering (like [Maven Resource
Plugin|https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html])
* advanced templating
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MINVOKER-182) Different groovy versions on test classpath can cause ClassCastException
[
https://issues.apache.org/jira/browse/MINVOKER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277497#comment-17277497
]
Bertrand Martin commented on MINVOKER-182:
--
Suggestion: Use [groovysh|https://groovy-lang.org/groovysh.html] to run
*verify.groovy*, so there is no conflict with the current JVM and whatever
dependencies are loaded by the project being tested with maven-invoker-plugin.
> Different groovy versions on test classpath can cause ClassCastException
>
>
> Key: MINVOKER-182
> URL: https://issues.apache.org/jira/browse/MINVOKER-182
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Andrew Schurman
>Priority: Minor
>
> When {{addTestClassPath}} is set and you have a different version of groovy
> than invoker on your classpath, you will run into {{ClassCastException}} when
> pre-/post- build hooks are run for tests. This occurs due to invoker creating
> groovy scripts in its version of groovy, but using a different version of
> groovy as the runtime (since test classpath elements are loaded first when
> {{addTestClassPath=true}}).
> In my specific case, I had a transitive dependency on groovy 1.7, but invoker
> uses groovy 2.0. Being transitive does make it harder to spot, but
> more importantly you may not have access to the dependency that depends on
> groovy. This could make swapping groovy versions impossible depending on the
> gap between versions.
> Stack trace:
> {code}
> groovy.lang.GroovyRuntimeException: Failed to create Script instance for
> class: class Script1. Reason: java.lang.ClassCastException: Script1 cannot be
> cast to groovy.lang.GroovyObject
> at
> org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:443)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:625)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:516)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:556)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:527)
> at
> org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:83)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:249)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:177)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1692)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1360)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuilds(AbstractInvokerMojo.java:1210)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.execute(AbstractInvokerMojo.java:723)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException
[jira] [Commented] (MINVOKER-274) Use Groovy 3.x to prevent Java9+ warnings about Groovy 2.x using illegal reflection
[
https://issues.apache.org/jira/browse/MINVOKER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277496#comment-17277496
]
Bertrand Martin commented on MINVOKER-274:
--
Suggestion: Use [groovysh|https://groovy-lang.org/groovysh.html] to run
*verify.groovy*, so there is no conflict with the current JVM and whatever
dependencies are loaded by the project being tested with maven-invoker-plugin.
> Use Groovy 3.x to prevent Java9+ warnings about Groovy 2.x using illegal
> reflection
> ---
>
> Key: MINVOKER-274
> URL: https://issues.apache.org/jira/browse/MINVOKER-274
> Project: Maven Invoker Plugin
> Issue Type: Improvement
> Environment: JDK9+
>Reporter: Bertrand Martin
>Priority: Major
> Labels: Java8
>
> h1. Problem
> Running integration tests with *maven-invoker-plugin* in JDK with version >=
> 9 (incl. OpenJDK 11, 14, 15, etc.) will generate these un-aesthetic messages:
> {noformat}
> [INFO] run post-build script verify.groovy
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
> (file:/d:/Dev2/maven/repository/org/codehaus/groovy/groovy-all/2.4.8/groovy-all-2.4.8.jar)
> to method java.lang.Object.clone()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> h1. Specification
> Use Groovy 3.x which solved all illegal accesses that were in 2.x.
> Most current version is:
> {code:xml}
> org.codehaus.groovy
> groovy-all
> 3.0.7
> pom
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DOXIA-618) doxia-module-markdown: Reincorporate maven-site-plugin's Doxia-specific integration tests
Bertrand Martin created DOXIA-618: - Summary: doxia-module-markdown: Reincorporate maven-site-plugin's Doxia-specific integration tests Key: DOXIA-618 URL: https://issues.apache.org/jira/browse/DOXIA-618 Project: Maven Doxia Issue Type: Task Components: Module - Markdown Reporter: Bertrand Martin h1. Specification The below Doxia issues have integration tests in *maven-site_plugin*: * DOXIA-473 * DOXIA-597 * DOXIA-571 * DOXIA-535 These tests can be reincorporated into *doxia-module-markdown* which has its own integration tests that run in *maven-site-plugin*. h1. Doc None h1. Test Integration tests must pass. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
Bertrand Martin created DOXIA-617:
-
Summary: doxia-module-markdown: Add support for --- header section
marks
Key: DOXIA-617
URL: https://issues.apache.org/jira/browse/DOXIA-617
Project: Maven Doxia
Issue Type: Improvement
Components: Module - Markdown
Reporter: Bertrand Martin
h1. Use Case
It is "generally" accepted that document header metadata in Markdown (like
_title_, _author_, etc.) must be specified inside a header section, delimited
with 3 dashes:
{noformat}
---
title: My Doc Title
author: Myself
keywords: great,doc
---
# Introduction
...
{noformat}
See:
* https://bookdown.org/yihui/rmarkdown/html-document.html
* https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
* https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
Currently, the only supported syntax for document header metadata is the very
same as above, but *without* the 3 dashes marking the header section:
{noformat}
title: My Doc Title
author: Myself
keywords: great,doc
# Introduction
...
{noformat}
h1. Specification
Enable the YAML Front Matter Extension of Flexmark so that such header is
processed automatically (nothing to code here!)
Keep the default behavior (we want backward compatibility) with the parsing of
metadatas (which won't be affected by the YAML Front Matter parsing).
h1. Doc
Update the documentation on how to use Markdown in Doxia. This feature
(document metadata) is currently not documented.
We should have a small guide on how to use Markdown in Doxia, and its specific
features (metadatas, macros, etc.)
h1. Test
Add corresponding unit tests and integration tests (for both old and new
syntaxes)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-521) Markdown: Allow using the standard "" for code blocks
[
https://issues.apache.org/jira/browse/DOXIA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257797#comment-17257797
]
Bertrand Martin commented on DOXIA-521:
---
[~michael-o] This issue can be closed along with DOXIA-616.
Things have been changed to satisfy both requests, as fenced code blocks are
now rendered as:
{code:html}
// Fenced Code Block 1
System.out.println("Hello, Fenced Code Block!");
{code}
i.e. {{}} inside a {{}}. So the skins don't need
to change their behavior to handle fenced code blocks, and popular highlighters
will just work out-of-the-box.
> Markdown: Allow using the standard "" for code blocks
>
>
> Key: DOXIA-521
> URL: https://issues.apache.org/jira/browse/DOXIA-521
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.6, 1.9
>Reporter: Santiago M. Mola
>Priority: Major
>
> Pegdown, as well as other Markdown parsers, translates code blocks to
> . This is the standard as per the Markdown specifications and both
> themes and tools (e.g. http://highlightjs.org/) rely on this syntax.
> However, the doxia markdown module overrides this behaviour and uses " class="source">. It would be nice to revert the default behaviour to the
> standard. If there are use cases for such an alternative syntax, it could be
> provided as an option.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MINVOKER-274) Use Groovy 3.x to prevent Java9+ warnings about Groovy 2.x using illegal reflection
Bertrand Martin created MINVOKER-274:
Summary: Use Groovy 3.x to prevent Java9+ warnings about Groovy
2.x using illegal reflection
Key: MINVOKER-274
URL: https://issues.apache.org/jira/browse/MINVOKER-274
Project: Maven Invoker Plugin
Issue Type: Improvement
Environment: JDK9+
Reporter: Bertrand Martin
h1. Problem
Running integration tests with *maven-invoker-plugin* in JDK with version >= 9
(incl. OpenJDK 11, 14, 15, etc.) will generate these un-aesthetic messages:
{noformat}
[INFO] run post-build script verify.groovy
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.codehaus.groovy.reflection.CachedClass
(file:/d:/Dev2/maven/repository/org/codehaus/groovy/groovy-all/2.4.8/groovy-all-2.4.8.jar)
to method java.lang.Object.clone()
WARNING: Please consider reporting this to the maintainers of
org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
{noformat}
h1. Specification
Use Groovy 3.x which solved all illegal accesses that were in 2.x.
Most current version is:
{code:xml}
org.codehaus.groovy
groovy-all
3.0.7
pom
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255563#comment-17255563
]
Bertrand Martin commented on DOXIA-616:
---
I found my way with clirr. I guess we'll remove it from Doxia in a separate
issue.
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255143#comment-17255143
]
Bertrand Martin commented on DOXIA-616:
---
Do we have a test project with content in md, apt and xdoc formats that are
supposed to produce the same output?
I was surprised not to find any integration test, but these are probably in
maven-site-plugin.
Right now, I'm fighting with the clirr-maven-plugin, which keeps telling me
that I'm not allowed to remove any class:
{noformat}
[INFO] --- clirr-maven-plugin:2.8:check (default) @ doxia-module-markdown ---
[INFO] Comparing to version: 1.9.1
[ERROR] 8001:
org.apache.maven.doxia.module.markdown.FlexmarkDoxiaNodeRenderer$Factory: Class
org.apache.maven.doxia.module.markdown.FlexmarkDoxiaNodeRenderer$Factory removed
{noformat}
I tried specifying to exclude this class in *pom.xml* but it doesn't work...
{code:xml}
org.codehaus.mojo
clirr-maven-plugin
org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer
org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer/Factory
org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer/*
org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer*
org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer/**
org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer**
{code}
Anyway, I'll pursue tomorrow ;-)
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255140#comment-17255140
]
Bertrand Martin commented on DOXIA-616:
---
It's the
[FlexmarkDoxiaNodeRenderer|https://github.com/sentrysoftware/maven-doxia/blob/master/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java]
class. If we remove it entirely, things work nicely with Flexmark's default
behavior (and still including Pegdown specific options).
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255137#comment-17255137
]
Bertrand Martin commented on DOXIA-616:
---
Actually, Flexmark does produce the {{}} element. It's Doxia's weird
implementation that specifically prevents the default behavior of Flexmark.
Maybe for very-old-backward compatibility?
I'll submit a PR where most of the specific code for handling Markdown is
removed (and let Flexmark do its job).
We'll see how this goes.
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-542) Markdown module converts all apostrophes to quotation marks
[
https://issues.apache.org/jira/browse/DOXIA-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255135#comment-17255135
]
Bertrand Martin commented on DOXIA-542:
---
I'm going to submit a PR for DOXIA-616. This PR (if things go well) will
greatly simplify the code and we'll see if that fixes also DOXIA-542 (this one)
at the same time. Ongoing tests...
> Markdown module converts all apostrophes to quotation marks
> ---
>
> Key: DOXIA-542
> URL: https://issues.apache.org/jira/browse/DOXIA-542
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.4, 1.7
>Reporter: Wolfgang Illmeyer
>Priority: Major
>
> Whenever there is some text in a markdown file containing an apostrophe
> (U+0027, e.g. »don't«), it is seemingly unconditionally replaced by a »right
> single quotation mark« (U+2019).
> The problem seems to be an out-of-whack »smart« feature of the underlying
> pegdown library, which is supposed to perform all kinds of typographic black
> magic. I'd suggest disabling that (or at least make it configurable), because
> apostrophes are not quotation marks and modern keyboard layouts have all the
> fancy typographic characters such as different length dashes, ellipses, and
> all sorts of quotation marks already easily available.
> The fix is relatively trivial:
> {code}
> ---
> a/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
> +++
> b/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
> @@ -70,7 +70,7 @@ public class MarkdownParser
> * The {@link PegDownProcessor} used to convert Pegdown documents to
> HTML.
> */
> protected static final PegDownProcessor PEGDOWN_PROCESSOR =
> -new PegDownProcessor( Extensions.ALL & ~Extensions.HARDWRAPS,
> Long.MAX_VALUE );
> +new PegDownProcessor( Extensions.ALL & ~Extensions.HARDWRAPS &
> ~Extensions.SMARTYPANTS, Long.MAX_VALUE );
>
> /**
> * Regex that identifies a multimarkdown-style metadata section at the
> start of the document
> {code}
> But this makes some tests fail and I didn't have the time to figure out how
> to fix them.
> Also, the resulting apostrophes probably need to be escaped in the HTML.
> I tested the patch with 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246033#comment-17246033
]
Bertrand Martin commented on DOXIA-616:
---
That's how one of the [most utilized
highlighter|https://highlightjs.org/usage/] works.
[Prim.js|https://prismjs.com/] on the other hand insists on having a {{}} element.
Anyway, most highlighters prefer the below syntax:
{code:html}
p { color: red }
{code}
The class indicating the language can however be set on an ancestor, so the
below will work as well, for example:
{code:html}
p { color: red }
{code}
I'm concerned that FlexMark doesn't produce the {{}} element, though...
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245837#comment-17245837
]
Bertrand Martin commented on DOXIA-616:
---
[~hboutemy][~michael-o][~michaelo] Guys, does this sound a reasonable
enhancement? (looks like to me...)
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-542) Markdown module converts all apostrophes to quotation marks
[
https://issues.apache.org/jira/browse/DOXIA-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244058#comment-17244058
]
Bertrand Martin commented on DOXIA-542:
---
Ding dong! 1-week-after friendly reminder! ;-)
> Markdown module converts all apostrophes to quotation marks
> ---
>
> Key: DOXIA-542
> URL: https://issues.apache.org/jira/browse/DOXIA-542
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.4, 1.7
>Reporter: Wolfgang Illmeyer
>Priority: Major
> Labels: close-pending
>
> Whenever there is some text in a markdown file containing an apostrophe
> (U+0027, e.g. »don't«), it is seemingly unconditionally replaced by a »right
> single quotation mark« (U+2019).
> The problem seems to be an out-of-whack »smart« feature of the underlying
> pegdown library, which is supposed to perform all kinds of typographic black
> magic. I'd suggest disabling that (or at least make it configurable), because
> apostrophes are not quotation marks and modern keyboard layouts have all the
> fancy typographic characters such as different length dashes, ellipses, and
> all sorts of quotation marks already easily available.
> The fix is relatively trivial:
> {code}
> ---
> a/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
> +++
> b/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
> @@ -70,7 +70,7 @@ public class MarkdownParser
> * The {@link PegDownProcessor} used to convert Pegdown documents to
> HTML.
> */
> protected static final PegDownProcessor PEGDOWN_PROCESSOR =
> -new PegDownProcessor( Extensions.ALL & ~Extensions.HARDWRAPS,
> Long.MAX_VALUE );
> +new PegDownProcessor( Extensions.ALL & ~Extensions.HARDWRAPS &
> ~Extensions.SMARTYPANTS, Long.MAX_VALUE );
>
> /**
> * Regex that identifies a multimarkdown-style metadata section at the
> start of the document
> {code}
> But this makes some tests fail and I didn't have the time to figure out how
> to fix them.
> Also, the resulting apostrophes probably need to be escaped in the HTML.
> I tested the patch with 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (DOXIA-542) Markdown module converts all apostrophes to quotation marks
[
https://issues.apache.org/jira/browse/DOXIA-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244058#comment-17244058
]
Bertrand Martin edited comment on DOXIA-542 at 12/4/20, 3:32 PM:
-
[~michael-o] Ding dong! 1-week-after friendly reminder! ;-)
was (Author: bertrandmartin):
Ding dong! 1-week-after friendly reminder! ;-)
> Markdown module converts all apostrophes to quotation marks
> ---
>
> Key: DOXIA-542
> URL: https://issues.apache.org/jira/browse/DOXIA-542
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.4, 1.7
>Reporter: Wolfgang Illmeyer
>Priority: Major
> Labels: close-pending
>
> Whenever there is some text in a markdown file containing an apostrophe
> (U+0027, e.g. »don't«), it is seemingly unconditionally replaced by a »right
> single quotation mark« (U+2019).
> The problem seems to be an out-of-whack »smart« feature of the underlying
> pegdown library, which is supposed to perform all kinds of typographic black
> magic. I'd suggest disabling that (or at least make it configurable), because
> apostrophes are not quotation marks and modern keyboard layouts have all the
> fancy typographic characters such as different length dashes, ellipses, and
> all sorts of quotation marks already easily available.
> The fix is relatively trivial:
> {code}
> ---
> a/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
> +++
> b/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
> @@ -70,7 +70,7 @@ public class MarkdownParser
> * The {@link PegDownProcessor} used to convert Pegdown documents to
> HTML.
> */
> protected static final PegDownProcessor PEGDOWN_PROCESSOR =
> -new PegDownProcessor( Extensions.ALL & ~Extensions.HARDWRAPS,
> Long.MAX_VALUE );
> +new PegDownProcessor( Extensions.ALL & ~Extensions.HARDWRAPS &
> ~Extensions.SMARTYPANTS, Long.MAX_VALUE );
>
> /**
> * Regex that identifies a multimarkdown-style metadata section at the
> start of the document
> {code}
> But this makes some tests fail and I didn't have the time to figure out how
> to fix them.
> Also, the resulting apostrophes probably need to be escaped in the HTML.
> I tested the patch with 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-542) Markdown module converts all apostrophes to quotation marks
[
https://issues.apache.org/jira/browse/DOXIA-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239398#comment-17239398
]
Bertrand Martin commented on DOXIA-542:
---
This is still true with the new FlexMark markdown Doxia module, unfortunately:
This Markdown:
{code}
I don't like this apos'trophe
{code}
is rendered as this HTML:
{code:html}
I don’t like this apos’trophe
{code}
Notice that the apostrophe has been modified. Which is wrong.
Also, when running this with {{mvn site site:run}}, the "wrong" apostrophe is
displayed as an unknown character ("?").
> Markdown module converts all apostrophes to quotation marks
> ---
>
> Key: DOXIA-542
> URL: https://issues.apache.org/jira/browse/DOXIA-542
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.4, 1.7
>Reporter: Wolfgang Illmeyer
>Priority: Major
> Labels: close-pending
>
> Whenever there is some text in a markdown file containing an apostrophe
> (U+0027, e.g. »don't«), it is seemingly unconditionally replaced by a »right
> single quotation mark« (U+2019).
> The problem seems to be an out-of-whack »smart« feature of the underlying
> pegdown library, which is supposed to perform all kinds of typographic black
> magic. I'd suggest disabling that (or at least make it configurable), because
> apostrophes are not quotation marks and modern keyboard layouts have all the
> fancy typographic characters such as different length dashes, ellipses, and
> all sorts of quotation marks already easily available.
> The fix is relatively trivial:
> {code}
> ---
> a/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
> +++
> b/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
> @@ -70,7 +70,7 @@ public class MarkdownParser
> * The {@link PegDownProcessor} used to convert Pegdown documents to
> HTML.
> */
> protected static final PegDownProcessor PEGDOWN_PROCESSOR =
> -new PegDownProcessor( Extensions.ALL & ~Extensions.HARDWRAPS,
> Long.MAX_VALUE );
> +new PegDownProcessor( Extensions.ALL & ~Extensions.HARDWRAPS &
> ~Extensions.SMARTYPANTS, Long.MAX_VALUE );
>
> /**
> * Regex that identifies a multimarkdown-style metadata section at the
> start of the document
> {code}
> But this makes some tests fail and I didn't have the time to figure out how
> to fix them.
> Also, the resulting apostrophes probably need to be escaped in the HTML.
> I tested the patch with 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Martin updated DOXIA-616:
--
Description:
h1. Use Case
Writers can specify the language used in a fenced code block (typically for
syntax highlighting), as in the example below:
{code}
```java
System.out.println("Beautiful\n");
```
{code}
Currently, the Doxia module for Markdown does not expose this information
("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
leverage it.
Produced HTML:
{code:html}
System.out.println("Beautiful\n");
{code}
Wanted result:
{code:html}
System.out.println("Beautiful\n");
{code}
h1. Specification
Un-comment this block:
https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
This should do the trick.
was:
h1. Use Case
Writers can specify the language used in a fenced code block (typically for
syntax highlighting), as in the example below:
{code}
```java
System.out.println("Beautiful\n");
```
{code}
Currently, the Doxia module for Markdown does not expose this information
("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
leverage it.
Produced HTML:
{code:html}
System.out.println("Beautiful\n");
{code}
Wanted result:
{code:html}
System.out.println("Beautiful\n");
{code}
h1. Specification
Un-comment this block:
https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
This should do the trick.
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
Bertrand Martin created DOXIA-616:
-
Summary: Markdown: Properly expose the language specified in
fenced code blocks
Key: DOXIA-616
URL: https://issues.apache.org/jira/browse/DOXIA-616
Project: Maven Doxia
Issue Type: Improvement
Components: Module - Markdown
Affects Versions: 1.9.1, 1.9, 1.8
Reporter: Bertrand Martin
h1. Use Case
Writers can specify the language used in a fenced code block (typically for
syntax highlighting), as in the example below:
{code}
```java
System.out.println("Beautiful\n");
```
{code}
Currently, the Doxia module for Markdown does not expose this information
("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
leverage it.
Produced HTML:
{code:html}
System.out.println("Beautiful\n");
{code}
Wanted result:
{code:html}
System.out.println("Beautiful\n");
{code}
h1. Specification
Un-comment this block:
https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSITE-842) $currentFileName and $alignedFileName are incorrect for Maven Report plugins that use several Sink instances
[
https://issues.apache.org/jira/browse/MSITE-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878722#comment-16878722
]
Bertrand Martin commented on MSITE-842:
---
[~michael-o] Has 3.8.1 been published? I can only see 3.7.1 on
mvnrepository.com. Thanks!
> $currentFileName and $alignedFileName are incorrect for Maven Report plugins
> that use several Sink instances
>
>
> Key: MSITE-842
> URL: https://issues.apache.org/jira/browse/MSITE-842
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: doxia integration
>Reporter: Bertrand Martin
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h1. Problem
> The _$currentFileName_ and _$alignedFileName_ macros work just fine for
> regular documents (from Markdown source, for example). But for multi-pages
> documents, like a Maven Report plugin would generate, these macros keep
> returning the name of main page of the report, rather than the page being
> rendered.
> h2. KmReference.java
> Maven Report plugin that use several instances of _Sink_
>
> {code:java}
> public class KmReference extends AbstractMavenReport {
> public String getOutputName() {
> return "km-reference";
> }
> ...
> @Override
> protected void executeReport(Locale locale) throws MavenReportException {
> ...
> // Create a new sink!
> Sink kmSink;
> try {
> kmSink = getSinkFactory().createSink(outputDirectory,
> pageFilename);
> } catch (IOException e) {
> throw new MavenReportException("Could not create sink for " +
> pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
> }
> {code}
> h2. site.vm
> {code}
> alignedFileName = $alignedFileName
> currentFileName = $currentFileName
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() = $docRenderingContext.getGenerator()
> getInputName() = $docRenderingContext.getInputName()
> getOutputName() = $docRenderingContext.getOutputName()
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = $docRenderingContext.getRelativePath()
> {code}
> h2. Resulting another-page.html
> This file is *not* km_reference.html, and stil:
> {code}
> alignedFileName = km-reference.html
> currentFileName = km-reference.html
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() =
> com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
> getInputName() = km-reference.html
> getOutputName() = km-reference.html
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = .
> {code}
> h1. Specification
> Modify _MultiPageSinkFactory.createSink( File outputDir, String outputName )_
> so that it creates a new _RenderingContext_ for each sub-sink, with the
> proper document name.
> Note: _MultiPageSinkFactory_ is a private class in
> **org.apache.maven.plugins.site.render.ReportDocumentRenderer.java**
> Note: Make sure that the new document name (which will end up in
> *$currentFileName*) is calculated relative to the project site output
> directory, so that sub-sink objects can be in sub-directories.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSITE-842) $currentFileName and $alignedFileName are incorrect for Maven Report plugins that use several Sink instances
[
https://issues.apache.org/jira/browse/MSITE-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Martin updated MSITE-842:
--
Description:
h1. Problem
The _$currentFileName_ and _$alignedFileName_ macros work just fine for regular
documents (from Markdown source, for example). But for multi-pages documents,
like a Maven Report plugin would generate, these macros keep returning the name
of main page of the report, rather than the page being rendered.
h2. KmReference.java
Maven Report plugin that use several instances of _Sink_
{code:java}
public class KmReference extends AbstractMavenReport {
public String getOutputName() {
return "km-reference";
}
...
@Override
protected void executeReport(Locale locale) throws MavenReportException {
...
// Create a new sink!
Sink kmSink;
try {
kmSink = getSinkFactory().createSink(outputDirectory,
pageFilename);
} catch (IOException e) {
throw new MavenReportException("Could not create sink for " +
pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
}
{code}
h2. site.vm
{code}
alignedFileName = $alignedFileName
currentFileName = $currentFileName
getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
getGenerator() = $docRenderingContext.getGenerator()
getInputName() = $docRenderingContext.getInputName()
getOutputName() = $docRenderingContext.getOutputName()
getParserId() = $docRenderingContext.getParserId()
getRelativePath() = $docRenderingContext.getRelativePath()
{code}
h2. Resulting another-page.html
This file is *not* km_reference.html, and stil:
{code}
alignedFileName = km-reference.html
currentFileName = km-reference.html
getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
getGenerator() =
com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
getInputName() = km-reference.html
getOutputName() = km-reference.html
getParserId() = $docRenderingContext.getParserId()
getRelativePath() = .
{code}
h1. Specification
Modify _MultiPageSinkFactory.createSink( File outputDir, String outputName )_
so that it creates a new _RenderingContext_ for each sub-sink, with the proper
document name.
Note: _MultiPageSinkFactory_ is a private class in
**org.apache.maven.plugins.site.render.ReportDocumentRenderer.java**
Note: Make sure that the new document name (which will end up in
*$currentFileName*) is calculated relative to the project site output
directory, so that sub-sink objects can be in sub-directories.
was:
h1. Problem
The _$currentFileName_ and _$alignedFileName_ macros work just fine for regular
documents (from Markdown source, for example). But for multi-pages documents,
like a Maven Report plugin would generate, these macros keep returning the name
of main page of the report, rather than the page being rendered.
h2. KmReference.java
Maven Report plugin that use several instances of _Sink_
{code:java}
public class KmReference extends AbstractMavenReport {
public String getOutputName() {
return "km-reference";
}
...
@Override
protected void executeReport(Locale locale) throws MavenReportException {
...
// Create a new sink!
Sink kmSink;
try {
kmSink = getSinkFactory().createSink(outputDirectory,
pageFilename);
} catch (IOException e) {
throw new MavenReportException("Could not create sink for " +
pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
}
{code}
h2. site.vm
{code}
alignedFileName = $alignedFileName
currentFileName = $currentFileName
getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
getGenerator() = $docRenderingContext.getGenerator()
getInputName() = $docRenderingContext.getInputName()
getOutputName() = $docRenderingContext.getOutputName()
getParserId() = $docRenderingContext.getParserId()
getRelativePath() = $docRenderingContext.getRelativePath()
{code}
h2. Resulting another-page.html
This file is *not* km_reference.html, and stil:
{code}
alignedFileName = km-reference.html
currentFileName = km-reference.html
getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
getGenerator() =
com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
getInputName() = km-reference.html
getOutputName() = km-reference.html
getParserId() = $docRenderingContext.getParserId()
getRelativePath() = .
{code}
h1. Specification
Modify the _DefaultSiteRenderer.createDocumentVelocityContext()_ method to
expose the actual name of the file being rendered.
Suggestion:
Property name: *renderedFileName*
Property value: {{File( siteContext.getProcessedContentOutput(),
docRenderingContext.getInputName().substring( 0, input.length() - 3 ) )}}
> $currentFileName and $alignedFileName are incorrect for Maven Report plugi
[jira] [Commented] (MSITE-842) $currentFileName and $alignedFileName are incorrect for Maven Report plugins that use several Sink instances
[
https://issues.apache.org/jira/browse/MSITE-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873581#comment-16873581
]
Bertrand Martin commented on MSITE-842:
---
Thank you [~michael-o]
You will find the Pull Request here:
https://github.com/apache/maven-site-plugin/pull/8
> $currentFileName and $alignedFileName are incorrect for Maven Report plugins
> that use several Sink instances
>
>
> Key: MSITE-842
> URL: https://issues.apache.org/jira/browse/MSITE-842
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: doxia integration
>Reporter: Bertrand Martin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h1. Problem
> The _$currentFileName_ and _$alignedFileName_ macros work just fine for
> regular documents (from Markdown source, for example). But for multi-pages
> documents, like a Maven Report plugin would generate, these macros keep
> returning the name of main page of the report, rather than the page being
> rendered.
> h2. KmReference.java
> Maven Report plugin that use several instances of _Sink_
>
> {code:java}
> public class KmReference extends AbstractMavenReport {
> public String getOutputName() {
> return "km-reference";
> }
> ...
> @Override
> protected void executeReport(Locale locale) throws MavenReportException {
> ...
> // Create a new sink!
> Sink kmSink;
> try {
> kmSink = getSinkFactory().createSink(outputDirectory,
> pageFilename);
> } catch (IOException e) {
> throw new MavenReportException("Could not create sink for " +
> pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
> }
> {code}
> h2. site.vm
> {code}
> alignedFileName = $alignedFileName
> currentFileName = $currentFileName
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() = $docRenderingContext.getGenerator()
> getInputName() = $docRenderingContext.getInputName()
> getOutputName() = $docRenderingContext.getOutputName()
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = $docRenderingContext.getRelativePath()
> {code}
> h2. Resulting another-page.html
> This file is *not* km_reference.html, and stil:
> {code}
> alignedFileName = km-reference.html
> currentFileName = km-reference.html
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() =
> com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
> getInputName() = km-reference.html
> getOutputName() = km-reference.html
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = .
> {code}
> h1. Specification
> Modify the _DefaultSiteRenderer.createDocumentVelocityContext()_ method to
> expose the actual name of the file being rendered.
> Suggestion:
> Property name: *renderedFileName*
> Property value: {{File( siteContext.getProcessedContentOutput(),
> docRenderingContext.getInputName().substring( 0, input.length() - 3 ) )}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (DOXIASITETOOLS-214) $currentFileName and $alignedFileName are incorrect for Maven Report plugins that use several Sink instances
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873021#comment-16873021
]
Bertrand Martin edited comment on DOXIASITETOOLS-214 at 6/26/19 7:43 AM:
-
This also means we should move this JIRA issue to the MSITE project and I will
update the description, which is now inaccurate. Thank you!
was (Author: bertrandmartin):
This also means we should move this JIRA issue to the MSITE project. Thank you!
> $currentFileName and $alignedFileName are incorrect for Maven Report plugins
> that use several Sink instances
>
>
> Key: DOXIASITETOOLS-214
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-214
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Problem
> The _$currentFileName_ and _$alignedFileName_ macros work just fine for
> regular documents (from Markdown source, for example). But for multi-pages
> documents, like a Maven Report plugin would generate, these macros keep
> returning the name of main page of the report, rather than the page being
> rendered.
> h2. KmReference.java
> Maven Report plugin that use several instances of _Sink_
>
> {code:java}
> public class KmReference extends AbstractMavenReport {
> public String getOutputName() {
> return "km-reference";
> }
> ...
> @Override
> protected void executeReport(Locale locale) throws MavenReportException {
> ...
> // Create a new sink!
> Sink kmSink;
> try {
> kmSink = getSinkFactory().createSink(outputDirectory,
> pageFilename);
> } catch (IOException e) {
> throw new MavenReportException("Could not create sink for " +
> pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
> }
> {code}
> h2. site.vm
> {code}
> alignedFileName = $alignedFileName
> currentFileName = $currentFileName
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() = $docRenderingContext.getGenerator()
> getInputName() = $docRenderingContext.getInputName()
> getOutputName() = $docRenderingContext.getOutputName()
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = $docRenderingContext.getRelativePath()
> {code}
> h2. Resulting another-page.html
> This file is *not* km_reference.html, and stil:
> {code}
> alignedFileName = km-reference.html
> currentFileName = km-reference.html
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() =
> com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
> getInputName() = km-reference.html
> getOutputName() = km-reference.html
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = .
> {code}
> h1. Specification
> Modify the _DefaultSiteRenderer.createDocumentVelocityContext()_ method to
> expose the actual name of the file being rendered.
> Suggestion:
> Property name: *renderedFileName*
> Property value: {{File( siteContext.getProcessedContentOutput(),
> docRenderingContext.getInputName().substring( 0, input.length() - 3 ) )}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DOXIASITETOOLS-214) $currentFileName and $alignedFileName are incorrect for Maven Report plugins that use several Sink instances
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873021#comment-16873021
]
Bertrand Martin commented on DOXIASITETOOLS-214:
This also means we should move this JIRA issue to the MSITE project. Thank you!
> $currentFileName and $alignedFileName are incorrect for Maven Report plugins
> that use several Sink instances
>
>
> Key: DOXIASITETOOLS-214
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-214
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Problem
> The _$currentFileName_ and _$alignedFileName_ macros work just fine for
> regular documents (from Markdown source, for example). But for multi-pages
> documents, like a Maven Report plugin would generate, these macros keep
> returning the name of main page of the report, rather than the page being
> rendered.
> h2. KmReference.java
> Maven Report plugin that use several instances of _Sink_
>
> {code:java}
> public class KmReference extends AbstractMavenReport {
> public String getOutputName() {
> return "km-reference";
> }
> ...
> @Override
> protected void executeReport(Locale locale) throws MavenReportException {
> ...
> // Create a new sink!
> Sink kmSink;
> try {
> kmSink = getSinkFactory().createSink(outputDirectory,
> pageFilename);
> } catch (IOException e) {
> throw new MavenReportException("Could not create sink for " +
> pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
> }
> {code}
> h2. site.vm
> {code}
> alignedFileName = $alignedFileName
> currentFileName = $currentFileName
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() = $docRenderingContext.getGenerator()
> getInputName() = $docRenderingContext.getInputName()
> getOutputName() = $docRenderingContext.getOutputName()
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = $docRenderingContext.getRelativePath()
> {code}
> h2. Resulting another-page.html
> This file is *not* km_reference.html, and stil:
> {code}
> alignedFileName = km-reference.html
> currentFileName = km-reference.html
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() =
> com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
> getInputName() = km-reference.html
> getOutputName() = km-reference.html
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = .
> {code}
> h1. Specification
> Modify the _DefaultSiteRenderer.createDocumentVelocityContext()_ method to
> expose the actual name of the file being rendered.
> Suggestion:
> Property name: *renderedFileName*
> Property value: {{File( siteContext.getProcessedContentOutput(),
> docRenderingContext.getInputName().substring( 0, input.length() - 3 ) )}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DOXIASITETOOLS-214) $currentFileName and $alignedFileName are incorrect for Maven Report plugins that use several Sink instances
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873020#comment-16873020
]
Bertrand Martin commented on DOXIASITETOOLS-214:
Thank you [~michael-o].
I've done the research:
* The {{$currentFileName}} macro is set with
{{RenderingContext.getOutputName()}} in
_DefaultSiteRenderer.createDocumentVelocityContext()_
* The _RenderingContext_ object comes from
_DocumentContent.getRenderingContext()_ in
_DefaultSiteRenderer.createSiteTemplateVelocityContext()_
* _DocumentContent_ object comes from
_DefaultSiteRenderer.mergeDocumentIntoSite()_...
* ...which is called by _ReportDocumentRenderer.renderDocument()_ in
**maven-site-plugin**
_ReportDocumentRenderer.renderDocument()_ calls
_DefaultSiteRenderer.mergeDocumentIntoSite()_ for the main Sink and also for
every sub-sink in a multi-page report. These "sub-sinks" are declared the
private class _MultiPageSinkFactory_ with the
_MultiPageSinkFactory.createSink()_ method.
The problem is that every sub-sink uses the same _RenderingContext_ as the main
Sink, with the same result for _getOutputName()_.
So the problem is really in **maven-site-plugin** which calls
_DefaultSiteRenderer.mergeDocumentIntoSite()_ with a DocumentContent which
contains an inaccurate _RenderingContext_.
If you agree with this, I'll submit a Pull Request to fix this (with the
additional IT and the code fix).
> $currentFileName and $alignedFileName are incorrect for Maven Report plugins
> that use several Sink instances
>
>
> Key: DOXIASITETOOLS-214
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-214
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Problem
> The _$currentFileName_ and _$alignedFileName_ macros work just fine for
> regular documents (from Markdown source, for example). But for multi-pages
> documents, like a Maven Report plugin would generate, these macros keep
> returning the name of main page of the report, rather than the page being
> rendered.
> h2. KmReference.java
> Maven Report plugin that use several instances of _Sink_
>
> {code:java}
> public class KmReference extends AbstractMavenReport {
> public String getOutputName() {
> return "km-reference";
> }
> ...
> @Override
> protected void executeReport(Locale locale) throws MavenReportException {
> ...
> // Create a new sink!
> Sink kmSink;
> try {
> kmSink = getSinkFactory().createSink(outputDirectory,
> pageFilename);
> } catch (IOException e) {
> throw new MavenReportException("Could not create sink for " +
> pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
> }
> {code}
> h2. site.vm
> {code}
> alignedFileName = $alignedFileName
> currentFileName = $currentFileName
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() = $docRenderingContext.getGenerator()
> getInputName() = $docRenderingContext.getInputName()
> getOutputName() = $docRenderingContext.getOutputName()
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = $docRenderingContext.getRelativePath()
> {code}
> h2. Resulting another-page.html
> This file is *not* km_reference.html, and stil:
> {code}
> alignedFileName = km-reference.html
> currentFileName = km-reference.html
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() =
> com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
> getInputName() = km-reference.html
> getOutputName() = km-reference.html
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = .
> {code}
> h1. Specification
> Modify the _DefaultSiteRenderer.createDocumentVelocityContext()_ method to
> expose the actual name of the file being rendered.
> Suggestion:
> Property name: *renderedFileName*
> Property value: {{File( siteContext.getProcessedContentOutput(),
> docRenderingContext.getInputName().substring( 0, input.length() - 3 ) )}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DOXIASITETOOLS-214) $currentFileName and $alignedFileName are incorrect for Maven Report plugins that use several Sink instances
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872192#comment-16872192
]
Bertrand Martin commented on DOXIASITETOOLS-214:
Sure! Should I add an integration test to the Maven Site Plugin? (and
therefore, should we move this JIRA issue to MSITE project?)
> $currentFileName and $alignedFileName are incorrect for Maven Report plugins
> that use several Sink instances
>
>
> Key: DOXIASITETOOLS-214
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-214
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Problem
> The _$currentFileName_ and _$alignedFileName_ macros work just fine for
> regular documents (from Markdown source, for example). But for multi-pages
> documents, like a Maven Report plugin would generate, these macros keep
> returning the name of main page of the report, rather than the page being
> rendered.
> h2. KmReference.java
> Maven Report plugin that use several instances of _Sink_
>
> {code:java}
> public class KmReference extends AbstractMavenReport {
> public String getOutputName() {
> return "km-reference";
> }
> ...
> @Override
> protected void executeReport(Locale locale) throws MavenReportException {
> ...
> // Create a new sink!
> Sink kmSink;
> try {
> kmSink = getSinkFactory().createSink(outputDirectory,
> pageFilename);
> } catch (IOException e) {
> throw new MavenReportException("Could not create sink for " +
> pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
> }
> {code}
> h2. site.vm
> {code}
> alignedFileName = $alignedFileName
> currentFileName = $currentFileName
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() = $docRenderingContext.getGenerator()
> getInputName() = $docRenderingContext.getInputName()
> getOutputName() = $docRenderingContext.getOutputName()
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = $docRenderingContext.getRelativePath()
> {code}
> h2. Resulting another-page.html
> This file is *not* km_reference.html, and stil:
> {code}
> alignedFileName = km-reference.html
> currentFileName = km-reference.html
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() =
> com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
> getInputName() = km-reference.html
> getOutputName() = km-reference.html
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = .
> {code}
> h1. Specification
> Modify the _DefaultSiteRenderer.createDocumentVelocityContext()_ method to
> expose the actual name of the file being rendered.
> Suggestion:
> Property name: *renderedFileName*
> Property value: {{File( siteContext.getProcessedContentOutput(),
> docRenderingContext.getInputName().substring( 0, input.length() - 3 ) )}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DOXIASITETOOLS-214) $currentFileName and $alignedFileName are incorrect for Maven Report plugins that use several Sink instances
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16871793#comment-16871793
]
Bertrand Martin commented on DOXIASITETOOLS-214:
Sorry for the noob question, but what is an "IT"? (I sure can come up with a
PR, though... ;-) )
> $currentFileName and $alignedFileName are incorrect for Maven Report plugins
> that use several Sink instances
>
>
> Key: DOXIASITETOOLS-214
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-214
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Problem
> The _$currentFileName_ and _$alignedFileName_ macros work just fine for
> regular documents (from Markdown source, for example). But for multi-pages
> documents, like a Maven Report plugin would generate, these macros keep
> returning the name of main page of the report, rather than the page being
> rendered.
> h2. KmReference.java
> Maven Report plugin that use several instances of _Sink_
>
> {code:java}
> public class KmReference extends AbstractMavenReport {
> public String getOutputName() {
> return "km-reference";
> }
> ...
> @Override
> protected void executeReport(Locale locale) throws MavenReportException {
> ...
> // Create a new sink!
> Sink kmSink;
> try {
> kmSink = getSinkFactory().createSink(outputDirectory,
> pageFilename);
> } catch (IOException e) {
> throw new MavenReportException("Could not create sink for " +
> pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
> }
> {code}
> h2. site.vm
> {code}
> alignedFileName = $alignedFileName
> currentFileName = $currentFileName
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() = $docRenderingContext.getGenerator()
> getInputName() = $docRenderingContext.getInputName()
> getOutputName() = $docRenderingContext.getOutputName()
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = $docRenderingContext.getRelativePath()
> {code}
> h2. Resulting another-page.html
> This file is *not* km_reference.html, and stil:
> {code}
> alignedFileName = km-reference.html
> currentFileName = km-reference.html
> getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
> getGenerator() =
> com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
> getInputName() = km-reference.html
> getOutputName() = km-reference.html
> getParserId() = $docRenderingContext.getParserId()
> getRelativePath() = .
> {code}
> h1. Specification
> Modify the _DefaultSiteRenderer.createDocumentVelocityContext()_ method to
> expose the actual name of the file being rendered.
> Suggestion:
> Property name: *renderedFileName*
> Property value: {{File( siteContext.getProcessedContentOutput(),
> docRenderingContext.getInputName().substring( 0, input.length() - 3 ) )}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DOXIASITETOOLS-214) $currentFileName and $alignedFileName are incorrect for Maven Report plugins that use several Sink instances
Bertrand Martin created DOXIASITETOOLS-214:
--
Summary: $currentFileName and $alignedFileName are incorrect for
Maven Report plugins that use several Sink instances
Key: DOXIASITETOOLS-214
URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-214
Project: Maven Doxia Sitetools
Issue Type: Bug
Components: Site renderer
Reporter: Bertrand Martin
h1. Problem
The _$currentFileName_ and _$alignedFileName_ macros work just fine for regular
documents (from Markdown source, for example). But for multi-pages documents,
like a Maven Report plugin would generate, these macros keep returning the name
of main page of the report, rather than the page being rendered.
h2. KmReference.java
Maven Report plugin that use several instances of _Sink_
{code:java}
public class KmReference extends AbstractMavenReport {
public String getOutputName() {
return "km-reference";
}
...
@Override
protected void executeReport(Locale locale) throws MavenReportException {
...
// Create a new sink!
Sink kmSink;
try {
kmSink = getSinkFactory().createSink(outputDirectory,
pageFilename);
} catch (IOException e) {
throw new MavenReportException("Could not create sink for " +
pageFilename + " in " + outputDirectory.getAbsolutePath(), e);
}
{code}
h2. site.vm
{code}
alignedFileName = $alignedFileName
currentFileName = $currentFileName
getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
getGenerator() = $docRenderingContext.getGenerator()
getInputName() = $docRenderingContext.getInputName()
getOutputName() = $docRenderingContext.getOutputName()
getParserId() = $docRenderingContext.getParserId()
getRelativePath() = $docRenderingContext.getRelativePath()
{code}
h2. Resulting another-page.html
This file is *not* km_reference.html, and stil:
{code}
alignedFileName = km-reference.html
currentFileName = km-reference.html
getDoxiaSourcePath() = $docRenderingContext.getDoxiaSourcePath()
getGenerator() =
com.sentrysoftware.maven:patrolreport-maven-plugin:2.0:km-reference
getInputName() = km-reference.html
getOutputName() = km-reference.html
getParserId() = $docRenderingContext.getParserId()
getRelativePath() = .
{code}
h1. Specification
Modify the _DefaultSiteRenderer.createDocumentVelocityContext()_ method to
expose the actual name of the file being rendered.
Suggestion:
Property name: *renderedFileName*
Property value: {{File( siteContext.getProcessedContentOutput(),
docRenderingContext.getInputName().substring( 0, input.length() - 3 ) )}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
