[jira] [Commented] (DOXIA-730) Update Asciidoctor Doxia Modules in doxia-site
[ https://issues.apache.org/jira/browse/DOXIA-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818202#comment-17818202 ] Abel Salgado Romero commented on DOXIA-730: --- PR [https://github.com/apache/maven-doxia-site/pull/34] > Update Asciidoctor Doxia Modules in doxia-site > -- > > Key: DOXIA-730 > URL: https://issues.apache.org/jira/browse/DOXIA-730 > Project: Maven Doxia > Issue Type: Improvement >Reporter: Abel Salgado Romero >Priority: Major > > In v3.0.0, we renamed the current module and created a new one. > I am working on a PR to update the page > https://maven.apache.org/doxia/references/index.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIA-730) Update Asciidoctor Doxia Modules in doxia-site
Abel Salgado Romero created DOXIA-730: - Summary: Update Asciidoctor Doxia Modules in doxia-site Key: DOXIA-730 URL: https://issues.apache.org/jira/browse/DOXIA-730 Project: Maven Doxia Issue Type: Improvement Reporter: Abel Salgado Romero In v3.0.0, we renamed the current module and created a new one. I am working on a PR to update the page https://maven.apache.org/doxia/references/index.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-327) Support multi-language for menu "name"
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807905#comment-17807905 ] Abel Salgado Romero commented on DOXIASITETOOLS-327: Thanks! That works, but from the example and https://github.com/apache/maven-site-plugin/blob/d78b8da70fd186738707f14166812d721064b766/src/site/apt/examples/creating-content.apt.vm#L196 I understand one needs to copy the whole site.xml. Wouldn't it make sense to have a way to avoid that duplication? > Support multi-language for menu "name" > -- > > Key: DOXIASITETOOLS-327 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-327 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site model >Affects Versions: 2.0.0-M16 >Reporter: Abel Salgado Romero >Priority: Minor > Fix For: waiting-for-feedback > > Attachments: image-2024-01-16-23-19-41-511.png > > > The new v2.0.x-MX added multi-lang / locale support to build pages, but seems > the `site.xml` does not allow to change the name of a menu element. > For example, a page with "en" and "es" versions and menu "Hello", will show > "Hello" in the Spanish site too, no way to specify "Hola". > > I peeked at the code and I see two options: > # Modify MenuItem to allow a sub name element like ` locale="es">Hola` > # Allow injection of language ResourceBundle properties in the current > element: `` > I like the second and will try to explore that, I saw the generated code > provides a transformer method for values, just need to find how to inject > custom logic there 🤔 > !image-2024-01-16-23-19-41-511.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-327) Support multi-language for menu "name"
Abel Salgado Romero created DOXIASITETOOLS-327: -- Summary: Support multi-language for menu "name" Key: DOXIASITETOOLS-327 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-327 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site model Affects Versions: 2.0.0-M16 Reporter: Abel Salgado Romero Attachments: image-2024-01-16-23-19-41-511.png The new v2.0.x-MX added multi-lang / locale support to build pages, but seems the `site.xml` does not allow to change the name of a menu element. For example, a page with "en" and "es" versions and menu "Hello", will show "Hello" in the Spanish site too, no way to specify "Hola". I peeked at the code and I see two options: # Modify MenuItem to allow a sub name element like `Hola` # Allow injection of language ResourceBundle properties in the current element: `` I like the second and will try to explore that, I saw the generated code provides a transformer method for values, just need to find how to inject custom logic there 🤔 !image-2024-01-16-23-19-41-511.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MSITE-1000) Allow parametrisation of Doxia parser per file
[
https://issues.apache.org/jira/browse/MSITE-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807467#comment-17807467
]
Abel Salgado Romero edited comment on MSITE-1000 at 1/16/24 10:08 PM:
--
If I understand, this story is to allow clean configuration of other modules.
If it helps, you can have a look at how we hacked our way around the
limitations. It's similar to the proposal. This improvement is very appreciated
and I look forward to seeing this completed.
Here is how we do it, we added a custom element `` to the
configuration, which we simply parsed by hand accessing the POM's XML
(obviously IDE complain, but it works):
* Get Xpp3Dom
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L106-L108]
* Parse XML by hand to generate converted API object
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/SiteConversionConfigurationParser.java#L46-L80]
* Pass the specific API object to the converter
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L79]
The parser configuration is varied, strings (some could be enums), booleans,
and free key-value maps.
My only issue with the example is `parserConfigurations`, there should be a way
to identify the config owner, you could have AsciiDoc and MarkDown and each one
requires different configuation. I like having the tag be called ``
{{}}
{{ }}
{{ }}
{{ *{*}/apt/{*}*}}
{{ }}
{{ }}
{{ }}
{{ }}
{{ *{*}/apt/{*}*}}
{{ }}
{{ }}
{{}}
Instead of something with a tag like:
{{}}
{{ }}
{{ asciidoc}}
{{ }}
{{ *{*}/apt/{*}*}}
{{ }}
{{ }}
{{ }}
{{ markdownc}}
{{ }}
{{ *{*}/apt/{*}*}}
{{ }}
{{ }}
{{}}
was (Author: abel s.romero):
If I understand, this story is to allow clean configuration of other modules.
If it helps, you can have a look at how we hacked our way around the
limitations. It's similar to the proposal. This improvement is very appreciated
and I look forward to seeing this completed.
Here is how we do it, we added a custom element `` to the
configuration, which we simply parsed by hand accessing the POM's XML
(obviously IDE complain, but it works):
* Get Xpp3Dom
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L106-L108]
* Parse XML by hand to generate converted API object
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/SiteConversionConfigurationParser.java#L46-L80]
* Pass the specific API object to the converter
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L79]
The parser configuration is varied, strings (some could be enums), booleans,
and free key-value maps.
My only issue with the example is `parserConfigurations`, there should be a way
to identify the config owner, you could have AsciiDoc and MarkDown and each one
requires different configuation. I like having the tag be called ``
**/apt/**
**/apt/**
Instead of something with a tag like:
asciidoc
**/apt/**
markdownc
**/apt/**
> Allow parametrisation of Doxia parser per file
> --
>
> Key: MSITE-1000
> URL: https://issues.apache.org/jira/browse/MSITE-1000
> Project: Maven Site Plugin
> Issue Type: New Feature
> Components: doxia integration
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently only the attributes used for rendering the site can be
> parameterized in
> https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#attributes.
> There is no possibility to configure the parser in
> https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L322
> per document.
> This would be nice in the context of
> https://issues.apache.org/jira/browse/DOXIA-722 where generation of anchors
> should be switched on/off for certain documents. Also generation of comments
> may be desirable for certain documents.
> I propose the following additional plugin goal parameter:
> {code}
>
>
>
> **/apt/**
>
>
[jira] [Commented] (MSITE-1000) Allow parametrisation of Doxia parser per file
[
https://issues.apache.org/jira/browse/MSITE-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807467#comment-17807467
]
Abel Salgado Romero commented on MSITE-1000:
If I understand, this story is to allow clean configuration of other modules.
If it helps, you can have a look at how we hacked our way around the
limitations. It's similar to the proposal. This improvement is very appreciated
and I look forward to seeing this completed.
Here is how we do it, we added a custom element `` to the
configuration, which we simply parsed by hand accessing the POM's XML
(obviously IDE complain, but it works):
* Get Xpp3Dom
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L106-L108]
* Parse XML by hand to generate converted API object
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/SiteConversionConfigurationParser.java#L46-L80]
* Pass the specific API object to the converter
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L79]
The parser configuration is varied, strings (some could be enums), booleans,
and free key-value maps.
My only issue with the example is `parserConfigurations`, there should be a way
to identify the config owner, you could have AsciiDoc and MarkDown and each one
requires different configuation. I like having the tag be called ``
**/apt/**
**/apt/**
Instead of something with a tag like:
asciidoc
**/apt/**
markdownc
**/apt/**
> Allow parametrisation of Doxia parser per file
> --
>
> Key: MSITE-1000
> URL: https://issues.apache.org/jira/browse/MSITE-1000
> Project: Maven Site Plugin
> Issue Type: New Feature
> Components: doxia integration
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently only the attributes used for rendering the site can be
> parameterized in
> https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#attributes.
> There is no possibility to configure the parser in
> https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L322
> per document.
> This would be nice in the context of
> https://issues.apache.org/jira/browse/DOXIA-722 where generation of anchors
> should be switched on/off for certain documents. Also generation of comments
> may be desirable for certain documents.
> I propose the following additional plugin goal parameter:
> {code}
>
>
>
> **/apt/**
>
> false
> true
>
>
> {code}
> where {{parserConfigurations}} is an array of a complex type with (include)
> patterns on the source path (String array) and boolean methods for features.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807271#comment-17807271 ] Abel Salgado Romero commented on DOXIA-725: --- Thanks a lot for the explanations. Regardless, the original topic is resolved and the other issue I had with maven-site seems to be related to locale configuration (I need to dig deeper). This can be closed. I agree we can see how the changes evolve. Thanks again! > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806979#comment-17806979 ] Abel Salgado Romero commented on DOXIA-725: --- I don't mean to criticize the amazing work, but it's hard to consume those components. The relationship is non-obvious; for instance, you cannot use automatic bumping, and as shown, when you see incompatibilities the code does not reflect you should be using the same version [https://github.com/apache/maven-doxia-sitetools/blob/5fe4a4c5359e6a23b78f385e15f77767cadaee99/pom.xml#L32-L70.] Maybe a BOM could be published that takes care of the dependencies? > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806926#comment-17806926 ] Abel Salgado Romero commented on DOXIA-725: --- Thanks, wouldn't it make sense to merge all in the same repo under the same parent? Now that we have the chance to make breaking changes? > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806457#comment-17806457 ] Abel Salgado Romero edited comment on DOXIA-725 at 1/14/24 11:40 AM: - Thanks, [~kwin] but I am sorry to say that doesn't help me. I create a SiteRendererSink for tests only, that's where I found the incompatibility; because my tests cannot run now. My module contains a parser module [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,|https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,m] that what it's not being detected past `asciidoctor-maven-site 4.0.0-M4` because I see no logs and the associated parser [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParser.java] does not run at all. I suspect Modules need to be defined in a different way now? was (Author: abel s.romero): Thanks, [~kwin] but I am sorry to say that doesn't help me. I create a SiteRendererSink for tests only, that's where I found the incompatibility; because my tests cannot run now. My module contains a parser module [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,|https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,m] that what it's not being detected past `asciidoctor-maven-site 4.0.0-M4` because I see no logs and the associated parser [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParser.java] does not run at all. > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806457#comment-17806457 ] Abel Salgado Romero commented on DOXIA-725: --- Thanks, [~kwin] but I am sorry to say that doesn't help me. I create a SiteRendererSink for tests only, that's where I found the incompatibility; because my tests cannot run now. My module contains a parser module [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,|https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,m] that what it's not being detected past `asciidoctor-maven-site 4.0.0-M4` because I see no logs and the associated parser [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParser.java] does not run at all. > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-725) Latest doxia-coreM9 is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806321#comment-17806321 ] Abel Salgado Romero commented on DOXIA-725: --- I just noted that since asciidoctor-maven-site 4.0.0-M4 the modules are not even detected. I assume there are some internal big changes. I found this [https://cwiki.apache.org/confluence/display/MAVEN/Towards+Doxia+2.0.0+Stack#TowardsDoxia2.0.0Stack-ReportingPluginMaintainers,] but there's no migration guide or detail on what do to. > Latest doxia-coreM9 is not compatible with doxia-sitetools > -- > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Reporter: Abel Salgado Romero >Priority: Major > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIA-725) Latest doxia-coreM9 is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abel Salgado Romero updated DOXIA-725: -- Description: Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with `doxia-sitetools`. This commit [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] final methods where added to `AbstractSink` class, those are still present in sub-classes like `SiteRendererSink` which now fail instantiation with: ``` java.lang.IncompatibleClassChangeError: class org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final method org.apache.maven.doxia.sink.impl.AbstractSink.head( ``` was: Testing Milestones I found `doxia-core`M9 is not compatible with `doxia-sitetools`. This commit https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f final methods where added to `AbstractSink` class, those are still present in sub-classes like `SiteRendererSink` which now fail instantiation with: ``` java.lang.IncompatibleClassChangeError: class org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final method org.apache.maven.doxia.sink.impl.AbstractSink.head( ``` > Latest doxia-coreM9 is not compatible with doxia-sitetools > -- > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Reporter: Abel Salgado Romero >Priority: Major > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIA-725) Latest doxia-coreM9 is not compatible with doxia-sitetools
Abel Salgado Romero created DOXIA-725: - Summary: Latest doxia-coreM9 is not compatible with doxia-sitetools Key: DOXIA-725 URL: https://issues.apache.org/jira/browse/DOXIA-725 Project: Maven Doxia Issue Type: Improvement Reporter: Abel Salgado Romero Testing Milestones I found `doxia-core`M9 is not compatible with `doxia-sitetools`. This commit https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f final methods where added to `AbstractSink` class, those are still present in sub-classes like `SiteRendererSink` which now fail instantiation with: ``` java.lang.IncompatibleClassChangeError: class org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final method org.apache.maven.doxia.sink.impl.AbstractSink.head( ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1351) Confusing message when copying resources from project's baseDir
Abel Salgado Romero created MSHARED-1351: Summary: Confusing message when copying resources from project's baseDir Key: MSHARED-1351 URL: https://issues.apache.org/jira/browse/MSHARED-1351 Project: Maven Shared Components Issue Type: Improvement Components: maven-filtering Affects Versions: maven-filtering-3.3.1 Reporter: Abel Salgado Romero When the project base dir is used as the origin path, the relativize in https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259 resolves to empty string, resulting in nothing being displayed path after "from" in the console: ``` Copying 118 resources from to target/generated-docs ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MSHARED-1175) describe from and to in "Copying x resources" info message
[ https://issues.apache.org/jira/browse/MSHARED-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803556#comment-17803556 ] Abel Salgado Romero edited comment on MSHARED-1175 at 1/5/24 2:28 PM: -- This seems to create a confusing message when the project base dir is used as the origin path. The relativize here https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259 resolves to empty string, resulting in no path after "from": ``` Copying 118 resources from to target/generated-docs ``` was (Author: abel s.romero): This seems to create a confusing message when the project base dir is used as the origin path. The relativize here https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259 resolves to empty string, resulting in something like ``` Copying 118 resources from to target/generated-docs ``` > describe from and to in "Copying x resources" info message > -- > > Key: MSHARED-1175 > URL: https://issues.apache.org/jira/browse/MSHARED-1175 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-3.3.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: maven-filtering-3.3.1 > > > see MRESOURCES-292 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1175) describe from and to in "Copying x resources" info message
[ https://issues.apache.org/jira/browse/MSHARED-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803556#comment-17803556 ] Abel Salgado Romero commented on MSHARED-1175: -- This seems to create a confusing message when the project base dir is used as the origin path. The relativize here https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259 resolves to empty string, resulting in something like ``` Copying 118 resources from to target/generated-docs ``` > describe from and to in "Copying x resources" info message > -- > > Key: MSHARED-1175 > URL: https://issues.apache.org/jira/browse/MSHARED-1175 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-3.3.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: maven-filtering-3.3.1 > > > see MRESOURCES-292 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704993#comment-17704993
]
Abel Salgado Romero commented on MSITE-849:
---
Thanks!
I could test the latest 2.0.0-M6 with latest milestones for doxia and
fluido-skin and our Parser does not get invoked.
I traced it to
https://github.com/apache/maven-doxia-sitetools/blob/9b99ba879f29341c6c4aef93f23421ff304afa2b/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L203,
I am seeing in my test that `moduleBasedir` points to
`asciidoc-maven-site-example/target/generated-site/asciidoc`.
And that path is not ever created and if scanned is not going to contain the
sources wich are in `asciidoc-maven-site-example/src/site/asciidoc`.
Could it be some regression was introduced or is there some new configuration I
should set in my Module.
We are initializing it with
```
String sourceDirectory = asciidoc
String parserId = asciidoc
String... extensions: adoc, asciidoc
```
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: site_site.png
>
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702868#comment-17702868
]
Abel Salgado Romero commented on MNG-6965:
--
Thanks. I understand then that the version included in the installation is not
used or excluded somehow and can be ignored.
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3, 3.0, 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702608#comment-17702608
]
Abel Salgado Romero commented on MNG-6965:
--
The question is not whether this should be included by default, that's clear,
ppl should add it explicitly and that's what we do.
The questions are:
1. Whether we should set it as `compile` (last comment from [~michael-o] says
so ) or `provided` (here it's said provided
https://issues.apache.org/jira/browse/MNG-6965?focusedCommentId=17499419&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17499419).
2. What versions is used in runtime when users run `mvn` comand? The one in the
plugin dependencies or the one in Maven runtime?
Repeating last comment sorry, but if the answers are `use compile and the
version used is the one in runtime` that's not consistent with `compile` scope
definition.
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3, 3.0, 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702594#comment-17702594
]
Abel Salgado Romero commented on MNG-6965:
--
That was quick, thanks!
But the maven installation still contains a plexus-utils-3.5.1 under `lib`. So
I assume using `compile` is a temporal fix right? If not, then that means
plugins are free to use whatever plexus-utils version they need?
Having to set it as `compile` but then using the provided one in runtime is a
contradiction imho.
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3, 3.0, 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702532#comment-17702532
]
Abel Salgado Romero edited comment on MNG-6965 at 3/20/23 10:26 AM:
I just hit this upgrading our plugin CI to 3.9.1 and based on this conversation
is not clear to me if this is something that will be fixed or not. As reported,
`plexus-utils` as `provided` is no longer working and we need to add it as
`compile` to fix it, but this is also stated as an invalid configuration. May I
assume based on
https://issues.apache.org/jira/browse/MNG-6965?focusedCommentId=17499735&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17499735
this is be fixed in 3.9.2?
Thanks a lot for all the work!
was (Author: abel s.romero):
I just hit this upgrading our plugin CI to 3.9.1 and besd on this conversation
is not cret to me if this is something that will be fixed or not. As reported,
`plexus-utils` as `provided` is no longer working and we need to add as
`compile` to fix it, but this is also stated as a invalid configuration. May I
assume based on
https://issues.apache.org/jira/browse/MNG-6965?focusedCommentId=17499735&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17499735
this is be fixed in 3.9.2?
Thanks a lot for all the work!
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3, 3.0, 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702532#comment-17702532
]
Abel Salgado Romero commented on MNG-6965:
--
I just hit this upgrading our plugin CI to 3.9.1 and besd on this conversation
is not cret to me if this is something that will be fixed or not. As reported,
`plexus-utils` as `provided` is no longer working and we need to add as
`compile` to fix it, but this is also stated as a invalid configuration. May I
assume based on
https://issues.apache.org/jira/browse/MNG-6965?focusedCommentId=17499735&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17499735
this is be fixed in 3.9.2?
Thanks a lot for all the work!
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3, 3.0, 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696627#comment-17696627
]
Abel Salgado Romero commented on MSITE-849:
---
Sure! I should be able to find some time during the week.
Thanks!
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: site_site.png
>
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17529268#comment-17529268
]
Abel Salgado Romero commented on MSITE-849:
---
I am afraid yes, just run the examples to reproduce with maven 3.8.5 and still
failing.
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: site_site.png
>
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7455) IllegalStateException in SessionScope during guice injection in multithreaded build
[
https://issues.apache.org/jira/browse/MNG-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521109#comment-17521109
]
Abel Salgado Romero commented on MNG-7455:
--
Thank you all for the support. As I understand this is not specific to the
aasciidoctor-maven-plugin so I'll wait, in the meantime FYI, we inject the
session because it's required to use MavenResourcesExecution, but we have been
considering removing it for some time in favor of simpler solution to copy
resource files
https://github.com/asciidoctor/asciidoctor-maven-plugin/issues/335.
So we could provide a fix if necessary.
> IllegalStateException in SessionScope during guice injection in multithreaded
> build
> ---
>
> Key: MNG-7455
> URL: https://issues.apache.org/jira/browse/MNG-7455
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.5
>Reporter: Emond Papegaaij
>Priority: Major
> Attachments: pom.xml.effective
>
>
> Since Maven 3.8.5 we are seeing intermittent failures with the stacktrace
> below. With 3.8.4 we did not have this issue. Looking at the changelog I
> suspect this regression is caused by MNG-7347.
> {code:java}
> 09:36:53 [mvn-builder-keyhub-manual] [INFO] ---
> asciidoctor-maven-plugin:2.2.2:process-asciidoc (output-html-nl) @
> keyhub-manual ---
> 09:36:53 [mvn-builder-keyhub-manual] [WARNING] Error injecting:
> org.asciidoctor.maven.AsciidoctorMojo
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, java.lang.IllegalStateException
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for field at org.asciidoctor.maven.AsciidoctorMojo.session(Unknown Source)
> while locating org.asciidoctor.maven.AsciidoctorMojo
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException
> (InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
> at com.google.inject.internal.InjectorImpl.getInstance
> (InjectorImpl.java:1086)
> at org.eclipse.sisu.space.AbstractDeferredClass.get
> (AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision
> (ProviderInternalFactory.java:85)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision
> (InternalFactoryToInitializableAdapter.java:57)
> at com.google.inject.internal.ProviderInternalFactory$1.call
> (ProviderInternalFactory.java:66)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:112)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:127)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision
> (ProvisionListenerStackCallback.java:66)
> at com.google.inject.internal.ProviderInternalFactory.circularGet
> (ProviderInternalFactory.java:61)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get
> (InternalFactoryToInitializableAdapter.java:47)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
> at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue
> (LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:255)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:520)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:210)
> at
> org.
[jira] [Commented] (MNG-7455) IllegalStateException in SessionScope during guice injection in multithreaded build
[
https://issues.apache.org/jira/browse/MNG-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520789#comment-17520789
]
Abel Salgado Romero commented on MNG-7455:
--
Hapy to help, b ut to speed this up:
* [~papegaaij] can you provide some reproducer? by multithread you mean
parallel in
https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3 ?
Are you running multiple asciidoctor plugins in different modules?
* [~michael-o] we directly inject the Sessin with @Inject
https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/0aa5121249890c5db7c78b7c82e2ad387f38719e/src/main/java/org/asciidoctor/maven/AsciidoctorMojo.java#L142-L143.
Would it be recommended to use Provider instead?
> IllegalStateException in SessionScope during guice injection in multithreaded
> build
> ---
>
> Key: MNG-7455
> URL: https://issues.apache.org/jira/browse/MNG-7455
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.5
>Reporter: Emond Papegaaij
>Priority: Major
>
> Since Maven 3.8.5 we are seeing intermittent failures with the stacktrace
> below. With 3.8.4 we did not have this issue. Looking at the changelog I
> suspect this regression is caused by MNG-7347.
> {code:java}
> 09:36:53 [mvn-builder-keyhub-manual] [INFO] ---
> asciidoctor-maven-plugin:2.2.2:process-asciidoc (output-html-nl) @
> keyhub-manual ---
> 09:36:53 [mvn-builder-keyhub-manual] [WARNING] Error injecting:
> org.asciidoctor.maven.AsciidoctorMojo
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, java.lang.IllegalStateException
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for field at org.asciidoctor.maven.AsciidoctorMojo.session(Unknown Source)
> while locating org.asciidoctor.maven.AsciidoctorMojo
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException
> (InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
> at com.google.inject.internal.InjectorImpl.getInstance
> (InjectorImpl.java:1086)
> at org.eclipse.sisu.space.AbstractDeferredClass.get
> (AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision
> (ProviderInternalFactory.java:85)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision
> (InternalFactoryToInitializableAdapter.java:57)
> at com.google.inject.internal.ProviderInternalFactory$1.call
> (ProviderInternalFactory.java:66)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:112)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:127)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision
> (ProvisionListenerStackCallback.java:66)
> at com.google.inject.internal.ProviderInternalFactory.circularGet
> (ProviderInternalFactory.java:61)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get
> (InternalFactoryToInitializableAdapter.java:47)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
> at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue
> (LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:255)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:520)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.Multi
[jira] [Commented] (DOXIASITETOOLS-225) Support providing the source reference to Doxia Parsers
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465047#comment-17465047 ] Abel Salgado Romero commented on DOXIASITETOOLS-225: I guess the comment is related to replacing String reference with an interface. I am more of a "baby steps" person, I'd like to integrate the current version in the plugin I maintain and then if I need anything else, we can explore options. Doesn't seem like there's any one asking for it, and it breaks binary compatibility. > Support providing the source reference to Doxia Parsers > --- > > Key: DOXIASITETOOLS-225 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-225 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.9.2 >Reporter: Herve Boutemy >Priority: Major > > Doxia Sitetools part of the work started in DOXIA-614 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (DOXIASITETOOLS-238) Allow passing input file name as referece to doxia parsers
Abel Salgado Romero created DOXIASITETOOLS-238: -- Summary: Allow passing input file name as referece to doxia parsers Key: DOXIASITETOOLS-238 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-238 Project: Maven Doxia Sitetools Issue Type: New Feature Affects Versions: 1.11.1 Reporter: Abel Salgado Romero https://issues.apache.org/jira/browse/DOXIA-614 fixed Doxia to allow parsers to receive a reference (String) to the original source being processed. Currently only the Reader was available preventing parsers from reporting the user where was a possible issue. However, parsers still receive 'null' since the Doxia-sitetools does not pass the reference in https://github.com/apache/maven-doxia-sitetools/blob/91b40d4873fef87b4c5241d332de224ff0e59946/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L435. To fix this, we should call `parse(Reader,String,Sink,String)` being the last String the reference value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DOXIASITETOOLS-227) Throwing "new ParseException(message)" shows message with "line [-1]"
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463620#comment-17463620
]
Abel Salgado Romero commented on DOXIASITETOOLS-227:
Thanks a lot!
Already validated, I am overriding the dependencies manually like. But I
wonder, is this something we can openly suggest to users of our doxia module?
Or just a "run at your own risk" workaround?
{{
org.apache.maven.plugins
maven-site-plugin
3.9.1
true
true
false
en
UTF-8
UTF-8
font
coderay
style
2
org.asciidoctor
asciidoctor-maven-plugin
${asciidoctor.maven.plugin.version}
org.apache.maven.doxia
doxia-site-renderer
1.11.2-SNAPSHOT
org.apache.maven.doxia
doxia-core
1.11.1
}}
> Throwing "new ParseException(message)" shows message with "line [-1]"
> -
>
> Key: DOXIASITETOOLS-227
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-227
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.9.1
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Minor
> Labels: intern
> Fix For: 1.10
>
>
> When throwing a 'org.apache.maven.doxia.parser.ParseException' from a Doxia
> module indicating only a message or source exception a message pointing to
> line -1 is show in console.
> Exemple:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-cli) on
> project asciidoc-maven-site-example: Error parsing
> '/home/asalgadr/github/asciidoctor-maven-examples/asciidoc-maven-site-example/src/site/asciidoc/article.adoc':
> line [-1] Found 1 issue(s) of severity DEBUG or higher during rendering ->
> [Help 1]
>
> I would expect that in case the line is not initialized, no reference to it
> is shown in the console.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (DOXIASITETOOLS-227) Throwing "new ParseException(message)" shows message with "line [-1]"
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463433#comment-17463433 ] Abel Salgado Romero commented on DOXIASITETOOLS-227: Hi, I was checking the issue, but I am confused. Forcing `doxia-site-renderer` version in the `maven-site-plugin`it seems the fix is not in v1.9.2 as stated in this issue, but 1.10. Also, most recent `maven-site-plugin` (v3.9.1) still uses `doxia-site-renderer` v1.9.2. ¿What should be the recommended approach to use newer versions? > Throwing "new ParseException(message)" shows message with "line [-1]" > - > > Key: DOXIASITETOOLS-227 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-227 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.9.1 >Reporter: Abel Salgado Romero >Assignee: Michael Osipov >Priority: Minor > Labels: intern > Fix For: 1.9.2 > > > When throwing a 'org.apache.maven.doxia.parser.ParseException' from a Doxia > module indicating only a message or source exception a message pointing to > line -1 is show in console. > Exemple: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-cli) on > project asciidoc-maven-site-example: Error parsing > '/home/asalgadr/github/asciidoctor-maven-examples/asciidoc-maven-site-example/src/site/asciidoc/article.adoc': > line [-1] Found 1 issue(s) of severity DEBUG or higher during rendering -> > [Help 1] > > I would expect that in case the line is not initialized, no reference to it > is shown in the console. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DOXIASITETOOLS-219) fix javadoc issues with JDK 8 when generating documentation
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151329#comment-17151329
]
Abel Salgado Romero commented on DOXIASITETOOLS-219:
Made a proposal in [https://github.com/apache/maven-doxia-sitetools/pull/17.]
For the previously commented 2 points what I did was:
* For 1. Add the following configuration to `doxia-doc-renderer` module
{code:java}
org.apache.maven.plugins
maven-javadoc-plugin
plexus.requirement
f
{code}
{code:java}
{code}
* For 2. Remove the line, it seems to me to be something missing from an old
change?
> fix javadoc issues with JDK 8 when generating documentation
> ---
>
> Key: DOXIASITETOOLS-219
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-219
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
>Affects Versions: 1.9.2
>Reporter: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.9.3
>
>
> when building Doxia Sitetools release with JDK 8:
> {noformat}mvn -Papache-release package -Dgpg.skip{noformat}
> some javadoc issues cause build failure
> for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIASITETOOLS-219) fix javadoc issues with JDK 8 when generating documentation
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149718#comment-17149718
]
Abel Salgado Romero commented on DOXIASITETOOLS-219:
I am working on this pointing temporarilly to the snapshot version of modello.
Mostly filling "param" and "return" with descriptions from other methods, but I
found 2 references that I don't know what to proceed.
# In `AbstractITextRender` there's this old annotation. Should just mark is as
`{color:#629755}{{color}{color:#629755}@literal
{color}{color:#629755}@plexus.requirement}{color}`? I suspect that will break
something
{code:java}
/**
* @plexus.requirement
*/
protected Doxia doxia;
{code}
2. In `DocumentRender` line 70, there's a commented line with a
deprecated reference. Is it safe to assume is a typo an can be removed?
PS: I got it working for Java8, with 11 there were other errors with modules,
but I image we deal with them in another issue.
> fix javadoc issues with JDK 8 when generating documentation
> ---
>
> Key: DOXIASITETOOLS-219
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-219
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
>Affects Versions: 1.9.2
>Reporter: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.9.3
>
>
> when building Doxia Sitetools release with JDK 8:
> {noformat}mvn -Papache-release package -Dgpg.skip{noformat}
> some javadoc issues cause build failure
> for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-611) Throwing "new ParseException(message)" shows message with "line [-1]"
[ https://issues.apache.org/jira/browse/DOXIA-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148951#comment-17148951 ] Abel Salgado Romero commented on DOXIA-611: --- Sent a proposal to fix this one: [https://github.com/apache/maven-doxia-sitetools/pull/16.] It tries to modify the minimum ammout of code so the -1 is kept.-- But I think this could be better treated using a null value (requirs changing from int to Integer) instead of a -1. > Throwing "new ParseException(message)" shows message with "line [-1]" > - > > Key: DOXIA-611 > URL: https://issues.apache.org/jira/browse/DOXIA-611 > Project: Maven Doxia > Issue Type: Bug > Components: Site Renderer (moved to DOXIASITETOOLS) >Affects Versions: 1.9.1 >Reporter: Abel Salgado Romero >Priority: Minor > Labels: intern > > When throwing a 'org.apache.maven.doxia.parser.ParseException' from a Doxia > module indicating only a message or source exception a message pointing to > line -1 is show in console. > Exemple: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-cli) on > project asciidoc-maven-site-example: Error parsing > '/home/asalgadr/github/asciidoctor-maven-examples/asciidoc-maven-site-example/src/site/asciidoc/article.adoc': > line [-1] Found 1 issue(s) of severity DEBUG or higher during rendering -> > [Help 1] > > I would expect that in case the line is not initialized, no reference to it > is shown in the console. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DOXIASITETOOLS-225) Support providing the source reference to Doxia Parsers
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147408#comment-17147408
]
Abel Salgado Romero commented on DOXIASITETOOLS-225:
While working on the changes on the sitetools side, I found we have several
elements we can pass as source reference.
The original idea was a simple string, but thinking it through:
* should it be full path? or relative path?
* split filename and parent path in different fields?
* should we support other sources (e.g. remote URL) as discussed?
I can think of 3 options, (1) expose the metadata using and interface in
"doxia-core" and have for now a default implementation that returns the File.
{code:java}
interface SouceMetadata {
T reference
}
{code}
(2) `org.apache.maven.doxia.parser.Parser` generic like
{code:java}
public interface Parser {
void parse(Reader reader, Sink sink, T sourceMetadata) throws ParseException;
}
{code}
(3) combine both.
I preffer the second one, it offers total freedom to what info the parser can
obtain. For example, during site generation could be something like a
"FileSourceMetadata" containing 2 fields; the relative baseDir and the
filename, or directly the File refence. For other types of sources, like remote
url, just and URL.
> Support providing the source reference to Doxia Parsers
> ---
>
> Key: DOXIASITETOOLS-225
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-225
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.9.2
>Reporter: Herve Boutemy
>Priority: Major
>
> Doxia Sitetools part of the work started in DOXIA-614
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-614) Support obtaining the source reference in a Doxia Parser
[
https://issues.apache.org/jira/browse/DOXIA-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147404#comment-17147404
]
Abel Salgado Romero commented on DOXIA-614:
---
I have a local version working and using local SNAPSHOTS I could make a
successfull end to end test, including changes in sitetools. Here is the WIP
PR: https://github.com/apache/maven-doxia/pull/35.
However, I am struggling with 2 things and need some help:
* `clirr-maven-plugin` complains during verification about binary changes in
classes, which is normal. Making the changes to avoid this, makes no sense in
this case and implies boilerplate code that will be removed in step 3. How
should I deal with this? For now I resort to add `-Dclirr.skip` for my tests.
* I want to add tests for DefaultDoxia, but I need to inject some fake/mock
Parser's in the contained ParserManager. This is done by plexus, and I could
get an instance extending from `PlexusTestCase` (I found this
[https://codehaus-plexus.github.io/guides/writing-components/03_joys_of_tdd.html),]
but I don't see how to inject it. I tried this `getContainer().addComponent(
)` with no luck. Honestly, if possible I'd rather use Mockito in this cases to
avoid dependencies with DI and make fixures clearer. Is there a problem if I
add Mockito as dependency to the project? What's the minimum Java version to
support?
> Support obtaining the source reference in a Doxia Parser
>
>
> Key: DOXIA-614
> URL: https://issues.apache.org/jira/browse/DOXIA-614
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core, Modules, Site Renderer (moved to DOXIASITETOOLS)
>Affects Versions: 1.9.1
>Reporter: Abel Salgado Romero
>Priority: Major
>
> Currently, the 'org.apache.maven.doxia.parser.Parser' interface provides 2
> methods that parsers can implement, one with and the other without the source
> reference. However, in reality the one with the reference added in DOXIA-224
> is never invoked, thus making it unusable from maven-site-plugin.
> Methods are:
> * void parse( Reader source, Sink sink )
> * void parse( Reader source, Sink sink, String reference )
>
> 1. Base implementation 'org.apache.maven.doxia.parser.AbstractParser'
> ('doxia-core') of the reference method calls the other, removing the
> reference if it is provided.
> {code:java}
> public void parse( Reader source, Sink sink, String reference )
> throws ParseException
> {
> parse( source, sink );
> }{code}
> 2. In 'org.apache.maven.doxia.DefaultDoxia#parse' ('doxia-core') the parser
> method 'parser (reader, sink)' is called at the end, which means
> 'parser(reader, sink, reference)' is never used.
>
> {code:java}
> public void parse( Reader source, String parserId, Sink sink )
> throws ParserNotFoundException, ParseException
> {
> Parser parser = parserManager.getParser( parserId );
> parser.enableLogging( new PlexusLoggerWrapper( getLogger() ) );
> parser.parse( source, sink );
> }
> {code}
>
> 3. 'org.apache.maven.doxia.Doxia#parse(Reader source, String parserId, Sink
> sink )' and it's implementation 'DefaultDoxia' ('doxia-core') does not
> receive the source reference, so it cannot pass it in any way.
>
> For these 3 reasons,
> 'org.apache.maven.doxia.siterenderer.DefaultSiteRenderer#renderDocument'
> ('doxia-sitetools') who has the source reference is not able to pass it to
> the above components.
> To sum up, the chaing of calls is: DefaultSiteRenderer -> Doxia/DefaultDoxia
> -> Parser implementation (e.g. AbstractParser)
>
> After discussion with [~hboutemy] the proposal is to fix it in several steps
> to avoid using SNAPSHOTS and ensure no breaking points:
> # Change doxia-core components to support new method with "reference", still
> having both methods. This means, changing AbstractParser and it's
> implementations to recieve the "reference". This does not break anything
> since no one is using this param now.
> # Change doxia-sitetools's 'DefaultSiteRenderer' component to pass the
> reference to Doxia/DefautDoxia DOXIASITETOOLS-225.
> # Release new doxia-sitetools version.
> # Once released, modifty doxia-core components to pass the reference and
> remove the (Reader, Sink) method completely. Also, in advance that Parsers
> may need more information about the source, instead of passing "String
> reference", we will pass a new class "SourceMetadata" that encapsulates the
> "String reference. That way we can add more information in the future if
> needed.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6930) Cannot use lambda as argument in a method in Mojo
[
https://issues.apache.org/jira/browse/MNG-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147287#comment-17147287
]
Abel Salgado Romero commented on MNG-6930:
--
No problem, I cannot close it myself.
About the compat question, I just run tests myself to check compatibility.
> Cannot use lambda as argument in a method in Mojo
> -
>
> Key: MNG-6930
> URL: https://issues.apache.org/jira/browse/MNG-6930
> Project: Maven
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.6.0
>Reporter: Abel Salgado Romero
>Priority: Major
>
> I have a plugin with uses a component that receives a lambda as argument.
> When passing any lamba, for example the following empty one
>
> {code:java}
>
> Optional sourceDir = new SourceDirectoryLocator(sourceDirectory,
> project.getBasedir(), file -> {})
> .find();
> {code}
>
> `maven-plugin-plugin` fails with the error:
>
> {code:java}
>
> [ERROR] Failed to execute goal
> org.codehaus.plexus:plexus-component-metadata:1.5.5:generate-metadata
> (default) on project asciidoctor-maven-plugin: Error generating metadata: :
> Failed to extract descriptors: Index 9578 out of bounds for length 999 ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.codehaus.plexus:plexus-component-metadata:1.5.5:generate-metadata
> (default) on project asciidoctor-maven-plugin: Error generating metadata:
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
>
> {code}
>
>
> Passing `null` or an anonymous class like shown below works however.
>
> {code:java}
>
> Optional sourceDir = new SourceDirectoryLocator(sourceDirectory,
> project.getBasedir(),
> new Consumer() {
> @Override
> public void accept(File file) {
> getLog().info("sourceDirectory " + file + " does not exist");
> }
> })
> .find();
>
> {code}
>
>
> Also tested with the current SNAPSHOT and the issue still happens
> Here is the code to reprodude:
> [https://github.com/abelsromero/asciidoctor-maven-plugin/tree/maven-plugin-plugin-lambda-issue]
> . Just run `mvn clean test-compile` to see the error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DOXIA-614) Support obtaining the source reference in a Doxia Parser
[
https://issues.apache.org/jira/browse/DOXIA-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abel Salgado Romero updated DOXIA-614:
--
Description:
Currently, the 'org.apache.maven.doxia.parser.Parser' interface provides 2
methods that parsers can implement, one with and the other without the source
reference. However, in reality the one with the reference is never invoked,
thus making it unusable.
Methods are:
* void parse( Reader source, Sink sink )
* void parse( Reader source, Sink sink, String reference )
1. Base implementation 'org.apache.maven.doxia.parser.AbstractParser'
('doxia-core') of the reference method calls the other, removing the reference
if it is provided.
{code:java}
public void parse( Reader source, Sink sink, String reference )
throws ParseException
{
parse( source, sink );
}{code}
2. In 'org.apache.maven.doxia.DefaultDoxia#parse' ('doxia-core') the parser
method 'parser (reader, sink)' is called at the end, which means
'parser(reader, sink, reference)' is never used.
{code:java}
public void parse( Reader source, String parserId, Sink sink )
throws ParserNotFoundException, ParseException
{
Parser parser = parserManager.getParser( parserId );
parser.enableLogging( new PlexusLoggerWrapper( getLogger() ) );
parser.parse( source, sink );
}
{code}
3. 'org.apache.maven.doxia.Doxia#parse(Reader source, String parserId, Sink
sink )' and it's implementation 'DefaultDoxia' ('doxia-core') does not receive
the source reference, so it cannot pass it in any way.
For these 3 reasons,
'org.apache.maven.doxia.siterenderer.DefaultSiteRenderer#renderDocument'
('doxia-sitetools') who has the source reference is not able to pass it to the
above components.
To sum up, the chaing of calls is: DefaultSiteRenderer -> Doxia/DefaultDoxia ->
Parser implementation (e.g. AbstractParser)
After discussion with [~hboutemy] the proposal is to fix it in several steps to
avoid using SNAPSHOTS and ensure no breaking points:
# Change doxia-core components to support new method with "reference", still
having both methods. This means, changing AbstractParser and it's
implementations to recieve the "reference". This does not break anything since
no one is using this param now.
# Change doxia-sitetools's 'DefaultSiteRenderer' component to pass the
reference to Doxia/DefautDoxia.
# Release new doxia-sitetools version.
# Once released, modifty doxia-core components to pass the reference and
remove the (Reader, Sink) method completely. Also, in advance that Parsers may
need more information about the source, instead of passing "String reference",
we will pass a new class "SourceMetadata" that encapsulates the "String
regference. That way we can add more information in the future if needed.
was:
Currently, the 'org.apache.maven.doxia.parser.Parser' interface provides 2
methods that parsers can implement, one with and the other without the source
reference. However, in reality the one with the reference is never invoked,
thus making it unusable.
Methods are:
* void parse( Reader source, Sink sink )
* void parse( Reader source, Sink sink, String reference )
1. Base implementation 'org.apache.maven.doxia.parser.AbstractParser'
('doxia-core') of the reference method calls the other, removing the reference
if it is provided.
{code:java}
public void parse( Reader source, Sink sink, String reference )
throws ParseException
{
parse( source, sink );
}{code}
2. In 'org.apache.maven.doxia.DefaultDoxia#parse' ('doxia-core') the parser
method 'parser (reader, sink)' is called at the end, which means
'parser(reader, sink, reference)' is never used.
{code:java}
public void parse( Reader source, String parserId, Sink sink )
throws ParserNotFoundException, ParseException
{
Parser parser = parserManager.getParser( parserId );
parser.enableLogging( new PlexusLoggerWrapper( getLogger() ) );
parser.parse( source, sink );
}
{code}
3. 'org.apache.maven.doxia.Doxia#parse(Reader source, String parserId, Sink
sink )' and it's implementation 'DefaultDoxia' ('doxia-core') does not receive
the source reference, so it cannot pass it in any way.
For these 3 reasons,
'org.apache.maven.doxia.siterenderer.DefaultSiteRenderer#renderDocument'
('doxia-sitetools') who has the source reference is not able to pass it to the
above components.
To sum up, the chaing of calls is: DefaultSiteRenderer -> Doxia/DefaultDoxia ->
Parser implementation (e.g. AbstractParser)
After discussion with [~hboutemy] the proposal is to fix it in several steps to
avoid using SNAPSHOTS and ensure no breaking points:
# Change doxia-core components to support new method with "reference", still
having both methods. These means, changing AbstractParser and it's
implementations to recieve the "reference". This does not break anything since
no one is using this param now.
# Change doxia-sitetools'
[jira] [Created] (DOXIA-614) Support obtaining the source reference in a Doxia Parser
Abel Salgado Romero created DOXIA-614:
-
Summary: Support obtaining the source reference in a Doxia Parser
Key: DOXIA-614
URL: https://issues.apache.org/jira/browse/DOXIA-614
Project: Maven Doxia
Issue Type: Improvement
Components: Core, Modules, Site Renderer (moved to DOXIASITETOOLS)
Reporter: Abel Salgado Romero
Currently, the 'org.apache.maven.doxia.parser.Parser' interface provides 2
methods that parsers can implement, one with and the other without the source
reference. However, in reality the one with the reference is never invoked,
thus making it unusable.
Methods are:
* void parse( Reader source, Sink sink )
* void parse( Reader source, Sink sink, String reference )
1. Base implementation 'org.apache.maven.doxia.parser.AbstractParser'
('doxia-core') of the reference method calls the other, removing the reference
if it is provided.
{code:java}
public void parse( Reader source, Sink sink, String reference )
throws ParseException
{
parse( source, sink );
}{code}
2. In 'org.apache.maven.doxia.DefaultDoxia#parse' ('doxia-core') the parser
method 'parser (reader, sink)' is called at the end, which means
'parser(reader, sink, reference)' is never used.
{code:java}
public void parse( Reader source, String parserId, Sink sink )
throws ParserNotFoundException, ParseException
{
Parser parser = parserManager.getParser( parserId );
parser.enableLogging( new PlexusLoggerWrapper( getLogger() ) );
parser.parse( source, sink );
}
{code}
3. 'org.apache.maven.doxia.Doxia#parse(Reader source, String parserId, Sink
sink )' and it's implementation 'DefaultDoxia' ('doxia-core') does not receive
the source reference, so it cannot pass it in any way.
For these 3 reasons,
'org.apache.maven.doxia.siterenderer.DefaultSiteRenderer#renderDocument'
('doxia-sitetools') who has the source reference is not able to pass it to the
above components.
To sum up, the chaing of calls is: DefaultSiteRenderer -> Doxia/DefaultDoxia ->
Parser implementation (e.g. AbstractParser)
After discussion with [~hboutemy] the proposal is to fix it in several steps to
avoid using SNAPSHOTS and ensure no breaking points:
# Change doxia-core components to support new method with "reference", still
having both methods. These means, changing AbstractParser and it's
implementations to recieve the "reference". This does not break anything since
no one is using this param now.
# Change doxia-sitetools's 'DefaultSiteRenderer' component to pass the
reference to Doxia/DefautDoxia.
# Release new doxia-sitetools version.
# Once released, modifty doxia-core components to pass the reference and
remove the (Reader, Sink) method completely. Also, in advance that Parsers may
need more information about the source, instead of passing "String reference",
we will pass a new class "SourceMetadata" that encapsulates the "String
regference. That way we can add more information in the future if needed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-555) Footer overrides for FO/PDF outputs
[ https://issues.apache.org/jira/browse/DOXIA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146832#comment-17146832 ] Abel Salgado Romero commented on DOXIA-555: --- Here is the example related to the use case [~slachiewicz] was mentioning -> [https://github.com/abelsromero/asciidoctor-maven-examples/tree/poc/show-doxia-error-without-source-file.] Preamble: asciidoctor-maven-plugun has 2 modes, "Mojo" in which we do parse files manually, in this case we can get the source file and report it in the error. In the other mode, "site-integration" (class "AsciidoctorDoxiaParser") we extend "XhtmlParser" with provides the method "parse(Reader reader, Sink sink)" with no reference to the source file. In this example, we show how under the same case in the site integration we cannot obtain the source file, so the user is left without a clue where to begin with. To reproduce: # Clone # To see the error with filename in "mojo" go into "asciidoc-to-html-example" folder and run "mvn". You'll see the ERROR message pointing to "ERROR: example-manual.adoc" file. # To see the error without filename in th e"site" integration, go tino "asciidoc-maven-site-example" folder run "mvn site:site" and you' see "ERROR: line 42: ", with no way to see which file from the 3 in the project failed. > Footer overrides for FO/PDF outputs > --- > > Key: DOXIA-555 > URL: https://issues.apache.org/jira/browse/DOXIA-555 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - FO >Reporter: Alex O'Ree >Priority: Major > Fix For: 2.0 > > Attachments: DOXIA-555.patch > > > Related [https://issues.apache.org/jira/browse/MPDF-81] > I have a use case where I cannot have the copyright symbol on the bottom of > generated PDF documents. Currently, it looks like the footer is hard coded > and cannot be customized. > [FoAggregateSink.java#l737|https://gitbox.apache.org/repos/asf?p=maven-doxia.git;a=blob;f=doxia-modules/doxia-module-fo/src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java;hb=HEAD#l737] > ideally, this should be configurable either properties or better yet, the pdf > descriptor document (maven-pdf-plugin). This would require a change in the > schema used for the pdf descriptor > [http://maven.apache.org/xsd/document-1.0.1.xsd] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DOXIA-555) Footer overrides for FO/PDF outputs
[ https://issues.apache.org/jira/browse/DOXIA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135294#comment-17135294 ] Abel Salgado Romero commented on DOXIA-555: --- Hi, don't mean to bother, but is there any advancement in this? From the asciidoctor-maven-plugin we would be interested now that we are improving error reporting for the site module. However, we cannot point to the exact file yet. > Footer overrides for FO/PDF outputs > --- > > Key: DOXIA-555 > URL: https://issues.apache.org/jira/browse/DOXIA-555 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - FO >Reporter: Alex O'Ree >Assignee: Herve Boutemy >Priority: Major > Fix For: 2.0 > > Attachments: DOXIA-555.patch > > > Related [https://issues.apache.org/jira/browse/MPDF-81] > I have a use case where I cannot have the copyright symbol on the bottom of > generated PDF documents. Currently, it looks like the footer is hard coded > and cannot be customized. > [FoAggregateSink.java#l737|https://gitbox.apache.org/repos/asf?p=maven-doxia.git;a=blob;f=doxia-modules/doxia-module-fo/src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java;hb=HEAD#l737] > ideally, this should be configurable either properties or better yet, the pdf > descriptor document (maven-pdf-plugin). This would require a change in the > schema used for the pdf descriptor > [http://maven.apache.org/xsd/document-1.0.1.xsd] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (DOXIA-611) Throwing "new ParseException(message)" shows message with "line [-1]"
Abel Salgado Romero created DOXIA-611: - Summary: Throwing "new ParseException(message)" shows message with "line [-1]" Key: DOXIA-611 URL: https://issues.apache.org/jira/browse/DOXIA-611 Project: Maven Doxia Issue Type: Bug Components: Site Renderer (moved to DOXIASITETOOLS) Affects Versions: 1.9.1 Reporter: Abel Salgado Romero When throwing a 'org.apache.maven.doxia.parser.ParseException' from a Doxia module indicating only a message or source exception a message pointing to line -1 is show in console. Exemple: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-cli) on project asciidoc-maven-site-example: Error parsing '/home/asalgadr/github/asciidoctor-maven-examples/asciidoc-maven-site-example/src/site/asciidoc/article.adoc': line [-1] Found 1 issue(s) of severity DEBUG or higher during rendering -> [Help 1] I would expect that in case the line is not initialized, no reference to it is shown in the console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6930) Cannot use lambda as argument in a method in Mojo
[
https://issues.apache.org/jira/browse/MNG-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127698#comment-17127698
]
Abel Salgado Romero commented on MNG-6930:
--
Forgot to come back, I got confused with some other errors and just today saw
the problem was in `plexus-component-metadata`, v1.7 already fixed this.
If I want to keep my plugin Java8 compatible are the latest versions safe?
> Cannot use lambda as argument in a method in Mojo
> -
>
> Key: MNG-6930
> URL: https://issues.apache.org/jira/browse/MNG-6930
> Project: Maven
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.6.0
>Reporter: Abel Salgado Romero
>Priority: Major
>
> I have a plugin with uses a component that receives a lambda as argument.
> When passing any lamba, for example the following empty one
>
> {code:java}
>
> Optional sourceDir = new SourceDirectoryLocator(sourceDirectory,
> project.getBasedir(), file -> {})
> .find();
> {code}
>
> `maven-plugin-plugin` fails with the error:
>
> {code:java}
>
> [ERROR] Failed to execute goal
> org.codehaus.plexus:plexus-component-metadata:1.5.5:generate-metadata
> (default) on project asciidoctor-maven-plugin: Error generating metadata: :
> Failed to extract descriptors: Index 9578 out of bounds for length 999 ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.codehaus.plexus:plexus-component-metadata:1.5.5:generate-metadata
> (default) on project asciidoctor-maven-plugin: Error generating metadata:
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
>
> {code}
>
>
> Passing `null` or an anonymous class like shown below works however.
>
> {code:java}
>
> Optional sourceDir = new SourceDirectoryLocator(sourceDirectory,
> project.getBasedir(),
> new Consumer() {
> @Override
> public void accept(File file) {
> getLog().info("sourceDirectory " + file + " does not exist");
> }
> })
> .find();
>
> {code}
>
>
> Also tested with the current SNAPSHOT and the issue still happens
> Here is the code to reprodude:
> [https://github.com/abelsromero/asciidoctor-maven-plugin/tree/maven-plugin-plugin-lambda-issue]
> . Just run `mvn clean test-compile` to see the error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6930) Cannot use lambda as argument in a method in Mojo
Abel Salgado Romero created MNG-6930:
Summary: Cannot use lambda as argument in a method in Mojo
Key: MNG-6930
URL: https://issues.apache.org/jira/browse/MNG-6930
Project: Maven
Issue Type: Bug
Components: Plugin API
Affects Versions: 3.6.0
Reporter: Abel Salgado Romero
I have a plugin with uses a component that receives a lambda as argument.
When passing any lamba, for example the following empty one
{code:java}
Optional sourceDir = new SourceDirectoryLocator(sourceDirectory,
project.getBasedir(), file -> {})
.find();
{code}
`maven-plugin-plugin` fails with the error:
{code:java}
[ERROR] Failed to execute goal
org.codehaus.plexus:plexus-component-metadata:1.5.5:generate-metadata (default)
on project asciidoctor-maven-plugin: Error generating metadata: : Failed to
extract descriptors: Index 9578 out of bounds for length 999 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.codehaus.plexus:plexus-component-metadata:1.5.5:generate-metadata (default)
on project asciidoctor-maven-plugin: Error generating metadata:
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
{code}
Passing `null` or an anonymous class like shown below works however.
{code:java}
Optional sourceDir = new SourceDirectoryLocator(sourceDirectory,
project.getBasedir(),
new Consumer() {
@Override
public void accept(File file) {
getLog().info("sourceDirectory " + file + " does not exist");
}
})
.find();
{code}
Also tested with the current SNAPSHOT and the issue still happens
Here is the code to reprodude:
[https://github.com/abelsromero/asciidoctor-maven-plugin/tree/maven-plugin-plugin-lambda-issue]
. Just run `mvn clean test-compile` to see the error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918920#comment-16918920
]
Abel Salgado Romero commented on MSITE-849:
---
Adding {{SessionScoped}} causes the following error and component not even
starts.
{code:java}
com.google.inject.ProvisionException: Unable to provision, see the following
errors:
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.asciidoctor.maven.site.AsciidoctorDoxiaParser,
annotation=[none]] outside of a scoping block
at org.asciidoctor.maven.site.AsciidoctorDoxiaParser.class(Unknown Source)
while locating org.asciidoctor.maven.site.AsciidoctorDoxiaParser
at ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.8.2,
parent: sun.misc.Launcher$AppClassLoader@18b4aac2] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.apache.maven.doxia.parser.Parser annotated with
@com.google.inject.name.Named(value=asciidoc)
{code}
And injecting {{MavenSession}} has the same effect as the {{MavenProject}}.
Checking the whole stacktrace I realize that during {{site:run}}, the Doxia
component runs inside a web context. And the call stack is completely different
from the one when building with {{site:site}} (see attachment below), there's
no Mojo involved. That makes me think that no Maven context is created and that
the error does in fact make a lot of sense. I can see how the web context is
created...
{code:java}
Caused by: com.google.inject.OutOfScopeException: Cannot access
Key[type=org.apache.maven.project.MavenProject, annotation=[none]] outside of a
scoping block
at org.apache.maven.execution.scope.internal.MojoExecutionScope$2.get
(MojoExecutionScope.java:122)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get
(InternalFactoryToProviderAdapter.java:39)
at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
at org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse
(AsciidoctorDoxiaParser.java:81)
at org.apache.maven.doxia.DefaultDoxia.parse (DefaultDoxia.java:65)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument
(DefaultSiteRenderer.java:436)
at org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument
(DoxiaDocumentRenderer.java:52)
at org.apache.maven.plugins.site.run.DoxiaFilter.doFilter
(DoxiaFilter.java:144)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter
(ServletHandler.java:1652)
at org.eclipse.jetty.servlet.ServletHandler.doHandle
(ServletHandler.java:585)
at org.eclipse.jetty.server.handler.ScopedHandler.handle
(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle
(SecurityHandler.java:577)
at org.eclipse.jetty.server.session.SessionHandler.doHandle
(SessionHandler.java:223)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle
(ContextHandler.java:1127)
at org.eclipse.jetty.servlet.ServletHandler.doScope
(ServletHandler.java:515)
at org.eclipse.jetty.server.session.SessionHandler.doScope
(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope
(ContextHandler.java:1061)
at org.eclipse.jetty.server.handler.ScopedHandler.handle
(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle
(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle (Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:311)
at org.eclipse.jetty.server.HttpConnection.onFillable
(HttpConnection.java:258)
at org.eclipse.jetty.io.AbstractConnection$2.run
(AbstractConnection.java:544)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob
(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run
(QueuedThreadPool.java:555)
at java.lang.Thread.run (Thread.java:748)
{code}
!site_site.png!
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
> Attachments: site_site.png
>
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the
[jira] [Updated] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abel Salgado Romero updated MSITE-849:
--
Attachment: site_site.png
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
> Attachments: site_site.png
>
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916833#comment-16916833
]
Abel Salgado Romero commented on MSITE-849:
---
Any idea on this topic?
PS: sorry to be a p**a, I'd really would like to see this progress :%
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16910019#comment-16910019
]
Abel Salgado Romero edited comment on MSITE-849 at 8/18/19 6:13 PM:
{quote}I don't think that Doxia should be tied to MavenProject. It can be used
and shall be used w/o Maven.{quote}
There's no other way to add additional configurations to custom converters, so
we just rolled with it.
If it should be in another way, that's definitely a question to the Doxia
Leads. Imho it's a bit too restrictive with what information it makes available
to converters.
{quote}If you say that the Asciidoc parser ist not init'ed. Are you sure that
this component is handled properly at all?{quote}
The no initialization is because (I assume) uses some lazy init. And since it
works fine with {{site:site}}, I assume it's correct.
was (Author: abel s.romero):
{quote}I don't think that Doxia should be tied to MavenProject. It can be used
and shall be used w/o Maven.{quote}
There's no other way to add additional configurations to custom converters, so
we just rolled with it.
If it should be in another way, that's definitely a question to the Doxia
Leads. Imho it's a bit too restrictive with what information it makes available
to converters.
{quote}If you say that the Asciidoc parser ist not init'ed. Are you sure that
this component is handled properly at all?{quote}
The no initialization is because -I assume- uses some lazy init. And since it
works fine with {{site:site}}, I assume it's correct.
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16910019#comment-16910019
]
Abel Salgado Romero commented on MSITE-849:
---
{quote}I don't think that Doxia should be tied to MavenProject. It can be used
and shall be used w/o Maven.{quote}
There's no other way to add additional configurations to custom converters, so
we just rolled with it.
If it should be in another way, that's definitely a question to the Doxia
Leads. Imho it's a bit too restrictive with what information it makes available
to converters.
{quote}If you say that the Asciidoc parser ist not init'ed. Are you sure that
this component is handled properly at all?{quote}
The no initialization is because -I assume- uses some lazy init. And since it
works fine with {{site:site}}, I assume it's correct.
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909978#comment-16909978
]
Abel Salgado Romero edited comment on MSITE-849 at 8/18/19 2:25 PM:
As a note to self. Directly injecting MavenProject I could narrow it to
{{org.apache.maven.doxia.parser.manager.DefaultParserManager::getParser( String
id)}}.
This holds a set of available Parsers, in this case the "asciidoc" parser is
not initialized (null in the internal map), so when trying retrieve it Guice
kicks in and initializes it, failing cause it cannot find the MavenProject in
the context.
When running {{mvn site:site}} it is correctly retrieved.
was (Author: abel s.romero):
As a note to self. Directly injecting MavenProject I could narrow it to
{{org.apache.maven.doxia.parser.manager.DefaultParserManager::getParser( String
id)}}.
This holds a set of available Parsers, in this case the "asciidoc" parser is
not initialized (null in the internal map), so when trying retrieve it Guice
kicks in and initializes it, failing cause it cannot find the MavenProject in
the context.
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909978#comment-16909978
]
Abel Salgado Romero commented on MSITE-849:
---
As a note to self. Directly injecting MavenProject I could narrow it to
{{org.apache.maven.doxia.parser.manager.DefaultParserManager::getParser( String
id)}}.
This holds a set of available Parsers, in this case the "asciidoc" parser is
not initialized (null in the internal map), so when trying retrieve it Guice
kicks in and initializes it, failing cause it cannot find the MavenProject in
the context.
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909970#comment-16909970
]
Abel Salgado Romero edited comment on MSITE-849 at 8/18/19 1:50 PM:
I did debug the {{SiteRunMojo}} and the MavenProject instance gets injected but
the thing is my class extends {{XhtmlParser}} which is a Doxia component. Which
has no getProject().
Should I address this issue with them? There are 3 projects "Maven Doxia",
"Maven Doxia Sitetools", "Maven Doxia Tools".
was (Author: abel s.romero):
I did debug the {{SiteRunMojo}} and the MavenProject instance gets injected but
the thing is my class extends {{XhtmlParser}} which is a Doxia component.
Should I address this issue with them? There are 3 projects "Maven Doxia",
"Maven Doxia Sitetools", "Maven Doxia Tools".
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909970#comment-16909970
]
Abel Salgado Romero commented on MSITE-849:
---
I did debug the {{SiteRunMojo}} and the MavenProject instance gets injected but
the thing is my class extends {{XhtmlParser}} which is a Doxia component.
Should I address this issue with them? There are 3 projects "Maven Doxia",
"Maven Doxia Sitetools", "Maven Doxia Tools".
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909959#comment-16909959
]
Abel Salgado Romero commented on MSITE-849:
---
Exact same as with @Inject :(
I am not a Guice expert by far, but seems to me the Maven instances is not
added to the context. If you can point me in some direction I can delve deeper.
But I don't know where to start looking.
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909940#comment-16909940
]
Abel Salgado Romero commented on MSITE-849:
---
Just tried injecting MavenProject with {{@Component}} as in the Mojo, but it's
null :/
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908427#comment-16908427
]
Abel Salgado Romero commented on MSITE-849:
---
Anything I can do to help let me know.
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6734) Ability to add Java sources to plugins classpath from .mvn directory
[ https://issues.apache.org/jira/browse/MNG-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908402#comment-16908402 ] Abel Salgado Romero commented on MNG-6734: -- The requirement could be rephrased indeed, the main idea is to be able to inject classes without needing additional modules like in the example: https://github.com/asciidoctor/asciidoctor-maven-examples/blob/f9580a7b22d015ce3f973099091f73802e867b3f/java-extension-example/asciidoctor-with-extension-example/pom.xml#L39. I understand you mean that a project could have something like a gradle "sourceSet" that is not included in the artifact but can be used by a plugin during it's execution, is that so? If so, it would fit perfectly the need. > Ability to add Java sources to plugins classpath from .mvn directory > > > Key: MNG-6734 > URL: https://issues.apache.org/jira/browse/MNG-6734 > Project: Maven > Issue Type: New Feature > Components: core >Reporter: Abel Salgado Romero >Priority: Minor > > In plugins like > [asciidoctor-maven-plugin|https://github.com/asciidoctor/asciidoctor-maven-plugin] > it is possible to add Java Asciidoctor extensions and other customizations > to the conversion process. > These need to be available to the asciidoctor-maven-plugin classpath and due > to how maven manages plugin's dependencies, this means that users need to > publish these extension in a maven repo or create multi-module projects like > in this example > https://github.com/asciidoctor/asciidoctor-maven-examples/tree/master/java-extension-example. > This is cumbersome and a bit of overkill when some users just want to add a > single class. > So, I wonder if would make sense to be able to add Java sources in the ".mvn" > directory that are compiled and added to the classpath so that maven plugins > can use them. > Ideally, to avoid classpath issues, I'd like to be able to tell which plugins > use the code, maybe with an XML descriptor or some directory convention. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abel Salgado Romero updated MSITE-849:
--
Description:
In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
MavenProject to obtain addition configurations from the pom.xml
(https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
This works fine with {{site:site}}, but when using {{site:run}} and accessing
one of the Asciidoc generated pages we get the error below.
I saw that:
* The error occurs when trying to retrieve the instance of the MavenProject.
* Behavior is the same if I directly inject the MavenProject instead of using a
provider. That is, {{site:site}} works, {{site:run}} fails because it cannot
find the instance.
{code:java}
HTTP ERROR 500
Problem accessing /hello.html. Reason:
Server Error
Caused by:
com.google.inject.ProvisionException: Unable to provision, see the following
errors:
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
outside of a scoping block
at
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
while locating org.apache.maven.project.MavenProject
1 error
at
com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
at
org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
{code}
* How to reproduce:
# clone https://github.com/asciidoctor/asciidoctor-maven-examples
# cd asciidoc-maven-site-example
# mvn site:run
# Access {{http://localhost:8080/hello.html}}
* Env:
{code}
$ mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: /home//.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
/home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
{code}
was:
In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
MavenProject to obtain addition configurations from the pom.xml
(https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
This works fine with {{site:site}}, but when using {{site:run}} and accessing
one of the Asciidoc generated pages we get the error below.
I saw that:
* The error occurs when trying to retrieve the instance of the MavenProject.
* Behavior is the same if I directly inject the MavenProject instead of using a
provider. That is, {{site:site}} works, {{site:run}} fails because it cannot
find the instance.
{code:java}
HTTP ERROR 500
Problem accessing /hello.html. Reason:
Server Error
Caused by:
com.google.inject.ProvisionException: Unable to provision, see the following
errors:
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
outside of a scoping block
at
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
while locating org.apache.maven.project.MavenProject
1 error
at
com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
at
org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
{code}
* How to reproduce:
# clone https://github.com/asciidoctor/asciidoctor-maven-examples
# cd asciidoc-maven-site-example
# Access {{http://localhost:8080/hello.html}}
* Env:
{code}
$ mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: /home//.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
/home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
{code}
> Unable to inject MavenProject wh
[jira] [Created] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
Abel Salgado Romero created MSITE-849:
-
Summary: Unable to inject MavenProject when using `mvn site:run`
Key: MSITE-849
URL: https://issues.apache.org/jira/browse/MSITE-849
Project: Maven Site Plugin
Issue Type: New Feature
Affects Versions: 3.8.2, 3.7.1
Reporter: Abel Salgado Romero
In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
MavenProject to obtain addition configurations from the pom.xml
(https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
This works fine with {{site:site}}, but when using {{site:run}} and accessing
one of the Asciidoc generated pages we get the error below.
I saw that:
* The error occurs when trying to retrieve the instance of the MavenProject.
* Behavior is the same if I directly inject the MavenProject instead of using a
provider. That is, {{site:site}} works, {{site:run}} fails because it cannot
find the instance.
{code:java}
HTTP ERROR 500
Problem accessing /hello.html. Reason:
Server Error
Caused by:
com.google.inject.ProvisionException: Unable to provision, see the following
errors:
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
outside of a scoping block
at
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
while locating org.apache.maven.project.MavenProject
1 error
at
com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
at
org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
{code}
* How to reproduce:
# clone https://github.com/asciidoctor/asciidoctor-maven-examples
# cd asciidoc-maven-site-example
# Access {{http://localhost:8080/hello.html}}
* Env:
{code}
$ mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: /home//.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
/home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (MNG-6734) Ability to add Java sources to plugins classpath from .mvn directory
Abel Salgado Romero created MNG-6734: Summary: Ability to add Java sources to plugins classpath from .mvn directory Key: MNG-6734 URL: https://issues.apache.org/jira/browse/MNG-6734 Project: Maven Issue Type: New Feature Components: core Reporter: Abel Salgado Romero In plugins like [asciidoctor-maven-plugin|https://github.com/asciidoctor/asciidoctor-maven-plugin] it is possible to add Java Asciidoctor extensions and other customizations to the conversion process. These need to be available to the asciidoctor-maven-plugin classpath and due to how maven manages plugin's dependencies, this means that users need to publish these extension in a maven repo or create multi-module projects like in this example https://github.com/asciidoctor/asciidoctor-maven-examples/tree/master/java-extension-example. This is cumbersome and a bit of overkill when some users just want to add a single class. So, I wonder if would make sense to be able to add Java sources in the ".mvn" directory that are compiled and added to the classpath so that maven plugins can use them. Ideally, to avoid classpath issues, I'd like to be able to tell which plugins use the code, maybe with an XML descriptor or some directory convention. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16460567#comment-16460567
]
Abel Salgado Romero commented on SUREFIRE-1255:
---
I already run some isolation back when we found it doing a general upgrade:
https://github.com/asciidoctor/asciidoctor-maven-plugin/pull/337.
If you want to reproduce it, just download the project from the repo
https://github.com/asciidoctor/asciidoctor-maven-plugin/, upgrade the surefire
version
https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/master/pom.xml#L346
and run the tests.
I honestly don't discard the issue is caused by some combination of factors,
but so far this is the only lead I found :%.
Note: the first test starts an embedded server and that can be missleading, add
an {{@Ignore}} if you prefer to see the issue with a normal test.
> Surefire 2.19.1 hangs before starting test execution
>
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of
> tests with no log output from the test itself, e.g.
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> [ERROR] Command was /bin/sh -c cd
> /home/travis/build/mxm/flink/flink-scala-shell/target &&
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1
> -XX:-UseGCOverheadLimit -jar
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the
> problem (Ran over 100 builds). It seems to be a race condition because it
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I
> haven't been able to reproduce the problem locally.
> More logs:
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458724#comment-16458724
]
Abel Salgado Romero commented on SUREFIRE-1255:
---
I don't think so.
Setting {{threadCount}} to 4 didn't help and in our case, the issue only
happens in Windows (7, 8.1 and Appveyor).
We just use the plugin as-is, the only special thing I can think of is that we
run spock tests using {{gmaven-plugin}}.
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
2.21.0
{code}
Maybe it's a different issue from that and this?
btw, thanks a lot for your attention :)
> Surefire 2.19.1 hangs before starting test execution
>
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of
> tests with no log output from the test itself, e.g.
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> [ERROR] Command was /bin/sh -c cd
> /home/travis/build/mxm/flink/flink-scala-shell/target &&
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1
> -XX:-UseGCOverheadLimit -jar
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the
> problem (Ran over 100 builds). It seems to be a race condition because it
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I
> haven't been able to reproduce the problem locally.
> More logs:
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458358#comment-16458358
]
Abel Salgado Romero commented on SUREFIRE-1255:
---
We are experiencing similar problems with {{asciidoctor-maven-plugin,}} an any
version above 2.19 (inclusive) makes the tests hang.
We are using the plugin as-is, with no fork or additional options
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/master/pom.xml#L343.]
Tests eventually run, but they hang and take hours when normally they take a
few minutes. Running with \{{-X}} doesn't show anything other than a big pause
before every test.
> Surefire 2.19.1 hangs before starting test execution
>
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of
> tests with no log output from the test itself, e.g.
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> [ERROR] Command was /bin/sh -c cd
> /home/travis/build/mxm/flink/flink-scala-shell/target &&
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1
> -XX:-UseGCOverheadLimit -jar
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the
> problem (Ran over 100 builds). It seems to be a race condition because it
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I
> haven't been able to reproduce the problem locally.
> More logs:
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MINVOKER-226) run goal failing on Windows + OracleJDK 8-144
[
https://issues.apache.org/jira/browse/MINVOKER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16181386#comment-16181386
]
Abel Salgado Romero edited comment on MINVOKER-226 at 9/26/17 7:27 PM:
---
You gave an idea and found a workaround...
Thing is I am running this from a normal windows shell (cmd.exe) but setting
the PATH to the maven I have installed with sdkman.
I just moved the mvn installation to another directory and it works, the same
exact files and it works.
I tested It many times moving it back and forth and this is the cause. I also
tried to reproduce it creating other long paths and with some directories whose
name start with dot, but no luck.
For instance, this is the path that fails
{{I:\babun\.babun\cygwin\home\abelsr\.sdkman\candidates\maven}}, but this works
{{I:\JavaStuff\.hidden\dir1\dir2\.hidden2\apache-maven-3.5.0}}.
So, I guess we can close the issue. I am not 100% comforted, but this is a
really weird combination.
Note that I've been using this maven settup for more than 3 years and nothing
ever happened and also, I don't recall any issues with previous version of
Java, btw, tested with Java9 and also fails.
was (Author: abel s.romero):
Found a workaround...
Thing is I am running this from a normal windows shell (cmd.exe) but setting
the PATH to the maven I have installed with sdkman.
I just moved the mvn installation to another directory and it works, the same
exact files and it works.
I tested It many times moving it back and forth and this is the cause. I also
tried to reproduce it creating other long paths and with some directories whose
name start with dot, but no luck.
For instance, this is the path that fails
{{I:\babun\.babun\cygwin\home\abelsr\.sdkman\candidates\maven}}, but this works
{{I:\JavaStuff\.hidden\dir1\dir2\.hidden2\apache-maven-3.5.0}}.
So, I guess we can close the issue. I am not 100% comforted, but this is a
really weird combination.
Note that I've been using this maven settup for more than 3 years and nothing
ever happened and also, I don't recall any issues with previous version of
Java, btw, tested with Java9 and also fails.
> run goal failing on Windows + OracleJDK 8-144
> -
>
> Key: MINVOKER-226
> URL: https://issues.apache.org/jira/browse/MINVOKER-226
> Project: Maven Invoker Plugin
> Issue Type: Bug
> Environment: Windows 7 and Windows 8.1 (2 different machines)
> Oracle JDK 8-144
> Maven 3.5.0
> maven-invoker-plugin: from 2.0.0 to 3.0.1
>Reporter: Abel Salgado Romero
>Priority: Minor
> Attachments: logs.txt
>
>
> maven-invoker-plugin (version 2.0.0) run goal started failing on Windows 8.1
> and Windows 7 with OracleJDK 8.144. It worked fine previously.
> Runs OK on MacOS (JDK 8-133 and 8-144), and Ubuntu TraviCI and Windows
> AppVeyor.
> Though the issue started with invoker 2.0.0, I am fine to focus on 3.0.1
> since it's the current version. Also 2.0.0 and 3.0.0 show a different error.
> With 3.0.1 everything seems to run fine but the validation scripts fail
> because they cannot find the generated files of the plugin being tested (see
> this branch
> https://github.com/abelsromero/asciidoctor-maven-plugin/tree/it_test_fail_on_Windows_jdk8_144).
> That's true, the target directory does not hold the generated files but
> running with -X shows that the goals are apparently executed as seen by the
> line
> {{[DEBUG] Executing: cmd.exe /X /C
> "I:\babun\.babun\cygwin\home\abelsr\.sdkman\candidates\maven\3.5.0\bin\mvn.cmd
> -B -X -D maven.repo.local=C:\Users\abelsr\.m2\repository -s
> C:\Users\abelsr\AppData\Local\Temp\invoker-settings4165519454880719356.xml
> clean asciidoctor:process-asciidoc"}}
> Running the same command without the custom settings file in the it-tests
> directory works fine and generates the files.
> NOTE: even if you see in the paths of the attached log that files are in a
> Babun home, I run the command {{mvn clean verify -Prun-its -X}} from a
> standard cmd shell.
> Could it be, that the plugin runs the tests on another directory?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MINVOKER-226) run goal failing on Windows + OracleJDK 8-144
[
https://issues.apache.org/jira/browse/MINVOKER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16181386#comment-16181386
]
Abel Salgado Romero commented on MINVOKER-226:
--
Found a workaround...
Thing is I am running this from a normal windows shell (cmd.exe) but setting
the PATH to the maven I have installed with sdkman.
I just moved the mvn installation to another directory and it works, the same
exact files and it works.
I tested It many times moving it back and forth and this is the cause. I also
tried to reproduce it creating other long paths and with some directories whose
name start with dot, but no luck.
For instance, this is the path that fails
{{I:\babun\.babun\cygwin\home\abelsr\.sdkman\candidates\maven}}, but this works
{{I:\JavaStuff\.hidden\dir1\dir2\.hidden2\apache-maven-3.5.0}}.
So, I guess we can close the issue. I am not 100% comforted, but this is a
really weird combination.
Note that I've been using this maven settup for more than 3 years and nothing
ever happened and also, I don't recall any issues with previous version of
Java, btw, tested with Java9 and also fails.
> run goal failing on Windows + OracleJDK 8-144
> -
>
> Key: MINVOKER-226
> URL: https://issues.apache.org/jira/browse/MINVOKER-226
> Project: Maven Invoker Plugin
> Issue Type: Bug
> Environment: Windows 7 and Windows 8.1 (2 different machines)
> Oracle JDK 8-144
> Maven 3.5.0
> maven-invoker-plugin: from 2.0.0 to 3.0.1
>Reporter: Abel Salgado Romero
>Priority: Minor
> Attachments: logs.txt
>
>
> maven-invoker-plugin (version 2.0.0) run goal started failing on Windows 8.1
> and Windows 7 with OracleJDK 8.144. It worked fine previously.
> Runs OK on MacOS (JDK 8-133 and 8-144), and Ubuntu TraviCI and Windows
> AppVeyor.
> Though the issue started with invoker 2.0.0, I am fine to focus on 3.0.1
> since it's the current version. Also 2.0.0 and 3.0.0 show a different error.
> With 3.0.1 everything seems to run fine but the validation scripts fail
> because they cannot find the generated files of the plugin being tested (see
> this branch
> https://github.com/abelsromero/asciidoctor-maven-plugin/tree/it_test_fail_on_Windows_jdk8_144).
> That's true, the target directory does not hold the generated files but
> running with -X shows that the goals are apparently executed as seen by the
> line
> {{[DEBUG] Executing: cmd.exe /X /C
> "I:\babun\.babun\cygwin\home\abelsr\.sdkman\candidates\maven\3.5.0\bin\mvn.cmd
> -B -X -D maven.repo.local=C:\Users\abelsr\.m2\repository -s
> C:\Users\abelsr\AppData\Local\Temp\invoker-settings4165519454880719356.xml
> clean asciidoctor:process-asciidoc"}}
> Running the same command without the custom settings file in the it-tests
> directory works fine and generates the files.
> NOTE: even if you see in the paths of the attached log that files are in a
> Babun home, I run the command {{mvn clean verify -Prun-its -X}} from a
> standard cmd shell.
> Could it be, that the plugin runs the tests on another directory?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MINVOKER-226) run goal failing on Windows + OracleJDK 8-144
Abel Salgado Romero created MINVOKER-226:
Summary: run goal failing on Windows + OracleJDK 8-144
Key: MINVOKER-226
URL: https://issues.apache.org/jira/browse/MINVOKER-226
Project: Maven Invoker Plugin
Issue Type: Bug
Environment: Windows 7 and Windows 8.1 (2 different machines)
Oracle JDK 8-144
Maven 3.5.0
maven-invoker-plugin: from 2.0.0 to 3.0.1
Reporter: Abel Salgado Romero
Priority: Minor
Attachments: logs.txt
maven-invoker-plugin (version 2.0.0) run goal started failing on Windows 8.1
and Windows 7 with OracleJDK 8.144. It worked fine previously.
Runs OK on MacOS (JDK 8-133 and 8-144), and Ubuntu TraviCI and Windows AppVeyor.
Though the issue started with invoker 2.0.0, I am fine to focus on 3.0.1 since
it's the current version. Also 2.0.0 and 3.0.0 show a different error.
With 3.0.1 everything seems to run fine but the validation scripts fail because
they cannot find the generated files of the plugin being tested (see this
branch
https://github.com/abelsromero/asciidoctor-maven-plugin/tree/it_test_fail_on_Windows_jdk8_144).
That's true, the target directory does not hold the generated files but running
with -X shows that the goals are apparently executed as seen by the line
{{[DEBUG] Executing: cmd.exe /X /C
"I:\babun\.babun\cygwin\home\abelsr\.sdkman\candidates\maven\3.5.0\bin\mvn.cmd
-B -X -D maven.repo.local=C:\Users\abelsr\.m2\repository -s
C:\Users\abelsr\AppData\Local\Temp\invoker-settings4165519454880719356.xml
clean asciidoctor:process-asciidoc"}}
Running the same command without the custom settings file in the it-tests
directory works fine and generates the files.
NOTE: even if you see in the paths of the attached log that files are in a
Babun home, I run the command {{mvn clean verify -Prun-its -X}} from a standard
cmd shell.
Could it be, that the plugin runs the tests on another directory?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MINVOKER-208) Documentation about invoker properties related to usage of options/parameters should be improved
[
https://issues.apache.org/jira/browse/MINVOKER-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381462#comment-15381462
]
Abel Salgado Romero commented on MINVOKER-208:
--
(y)
> Documentation about invoker properties related to usage of options/parameters
> should be improved
> -
>
> Key: MINVOKER-208
> URL: https://issues.apache.org/jira/browse/MINVOKER-208
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0
>
>
> The documentation
> http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#invokerPropertiesFile
> needed to be improved about usage of things like {{-DWhatEver}} that those
> things should be done with {{invoker.goals=..}} instead of
> {{invoker.mavenOpts=...}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MINVOKER-208) Documentation about invoker properties related to usage of options/parameters should be improved
[
https://issues.apache.org/jira/browse/MINVOKER-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381456#comment-15381456
]
Abel Salgado Romero commented on MINVOKER-208:
--
mavenOpts explanation is correct but can lead to confusion because no
alternative to pass environment variables is shown.
Adding additional explanation and example to goals should be enough.
Current text says:
{{# A comma or space separated list of goals/phases to execute, may}}
{{# specify an empty list to execute the default goal of the IT project}}
{{invoker.goals = clean install}}
This is the proposed alternative:
{{# A comma or space separated list of goals/phases to execute, may}}
{{# specify an empty list to execute the default goal of the IT project.}}
{{# Environment variables used by maven plugins can be added here}}
{{invoker.goals = clean install -Dplugin.variable=value}}
> Documentation about invoker properties related to usage of options/parameters
> should be improved
> -
>
> Key: MINVOKER-208
> URL: https://issues.apache.org/jira/browse/MINVOKER-208
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0
>
>
> The documentation
> http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#invokerPropertiesFile
> needed to be improved about usage of things like {{-DWhatEver}} that those
> things should be done with {{invoker.goals=..}} instead of
> {{invoker.mavenOpts=...}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381404#comment-15381404 ] Abel Salgado Romero edited comment on MINVOKER-198 at 7/17/16 3:59 PM: --- The issue was related to how the options where passed, the wrong option was used. Using the right one fixes the problem. was (Author: abel s.romero): The issue was related to how the options where passed, the wrong option was used. > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Linux/Mac >Reporter: Abel Salgado Romero > Fix For: waiting-for-feedback > > Attachments: mac_output.txt > > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abel Salgado Romero closed MINVOKER-198. Resolution: Not A Problem The issue was related to how the options where passed, the wrong option was used. > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Linux/Mac >Reporter: Abel Salgado Romero > Fix For: waiting-for-feedback > > Attachments: mac_output.txt > > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381403#comment-15381403 ] Abel Salgado Romero commented on MINVOKER-198: -- Thanks a lot for your support and explanation. I just used mavenOpts because it was the only thing that made some sense to me looking in the example in the documentation (http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#invokerPropertiesFile). It is the only place where a -D option is passed and goals does not mention that you can add options. Extending the explanation for goals saying you can add parameters would be great. > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Linux/Mac >Reporter: Abel Salgado Romero > Fix For: waiting-for-feedback > > Attachments: mac_output.txt > > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381305#comment-15381305 ] Abel Salgado Romero commented on MINVOKER-198: -- I created a branch with the examples required. Here is the branch: https://github.com/abelsromero/asciidoctor-maven-plugin/tree/support/maven-invoker-plugin_spaces_issue You'll see that the integration test 'src/it/article-html-command-with-spaces' fails with the message Error: Could not find or load main class source-highlighter=coderay" Inside the folder I created a plain maven project with the same configuration that you can run with the 'run.sh' found inside. Both the test and the plain project use the same configuration, but only the latests works. To see it working you can replace the 'toc' option by 'right' and you'll see that the index is generated on the other side of the page. Let me know if you need any assistance with it, and thanks for your support :) > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Linux/Mac >Reporter: Abel Salgado Romero > Fix For: waiting-for-feedback > > Attachments: mac_output.txt > > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370241#comment-15370241 ] Abel Salgado Romero commented on MINVOKER-198: -- What does 'waiting-for-feedback' mean? > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Linux/Mac >Reporter: Abel Salgado Romero > Fix For: waiting-for-feedback > > Attachments: mac_output.txt > > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146150#comment-15146150 ] Abel Salgado Romero edited comment on MINVOKER-198 at 2/13/16 7:35 PM: --- I've been doing some debugging and seems that the MAVEN_OPTS are properly captured (as seen in the code) and passed to the DefaultInvoker without modifications. Further debugging I get to the final command line call in org.codehaus.plexus.util.CommandLine:L670, and again the environment variable shows that MAVEN_OPTS is correctI am really confused :/ BTW, I updated the request, it only fails on Mac and Linux was (Author: abel s.romero): I've been doing some debugging and seems that the MAVEN_OPTS are properly captured (as seen in the code) and passed to the DefaultInvoker without modifications. Further debugging I get to the final command line call in org.codehaus.plexus.util.CommandLine:L670, and again the environment variable shows that MAVEN_OPTS is correctI am really confused :/ > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Linux/Mac >Reporter: Abel Salgado Romero > Attachments: mac_output.txt > > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146150#comment-15146150 ] Abel Salgado Romero commented on MINVOKER-198: -- I've been doing some debugging and seems that the MAVEN_OPTS are properly captured (as seen in the code) and passed to the DefaultInvoker without modifications. Further debugging I get to the final command line call in org.codehaus.plexus.util.CommandLine:L670, and again the environment variable shows that MAVEN_OPTS is correctI am really confused :/ > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Linux/Mac >Reporter: Abel Salgado Romero > Attachments: mac_output.txt > > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abel Salgado Romero updated MINVOKER-198: - Attachment: mac_output.txt Build output in debug (MacOS) > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Linux/Mac >Reporter: Abel Salgado Romero > Attachments: mac_output.txt > > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abel Salgado Romero updated MINVOKER-198: - Environment: Maven 3.3.9 and 3.2.5. Linux/Mac was: Maven 3.3.9 and 3.2.5. Win/Linux/Mac > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Linux/Mac >Reporter: Abel Salgado Romero > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
[ https://issues.apache.org/jira/browse/MINVOKER-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abel Salgado Romero updated MINVOKER-198: - Description: Seems that mavenOpts does some additional parsing and comand line arguments with spaces are not read correctly. This prevents writing tests that when run on console in a normal maven build they work. Here is an example of what I want to test: https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties If you see the "asciidoctor.attributes" is a chain with many internal parameters and spaces. This works on console, but not in the test. But the test fails with the message: Error: Could not find or load main class source-highlighter=coderay" was: Seems that mavenOpts does some additional parsing and comand line arguments with spaces and not read correctly. This prevents writting tests that when run from console in a normal maven build they work. Here is an example of what I want to test: https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties If you see the "asciidoctor.attributes" is a chain with many internal parameters and spaces. This works on console, but not in the test. But the test fails with the message: Error: Could not find or load main class source-highlighter=coderay" > mavenOpts in invoker.properties does not accept parameters with spaces > -- > > Key: MINVOKER-198 > URL: https://issues.apache.org/jira/browse/MINVOKER-198 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 2.0.0 > Environment: Maven 3.3.9 and 3.2.5. > Win/Linux/Mac >Reporter: Abel Salgado Romero > > Seems that mavenOpts does some additional parsing and comand line arguments > with spaces are not read correctly. > This prevents writing tests that when run on console in a normal maven build > they work. > Here is an example of what I want to test: > https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties > If you see the "asciidoctor.attributes" is a chain with many internal > parameters and spaces. This works on console, but not in the test. > But the test fails with the message: > Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINVOKER-198) mavenOpts in invoker.properties does not accept parameters with spaces
Abel Salgado Romero created MINVOKER-198: Summary: mavenOpts in invoker.properties does not accept parameters with spaces Key: MINVOKER-198 URL: https://issues.apache.org/jira/browse/MINVOKER-198 Project: Maven Invoker Plugin Issue Type: Bug Affects Versions: 2.0.0 Environment: Maven 3.3.9 and 3.2.5. Win/Linux/Mac Reporter: Abel Salgado Romero Seems that mavenOpts does some additional parsing and comand line arguments with spaces and not read correctly. This prevents writting tests that when run from console in a normal maven build they work. Here is an example of what I want to test: https://github.com/abelsromero/asciidoctor-maven-plugin/blob/attributes_command/src/it/article-html-attributes/invoker.properties If you see the "asciidoctor.attributes" is a chain with many internal parameters and spaces. This works on console, but not in the test. But the test fails with the message: Error: Could not find or load main class source-highlighter=coderay" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
