[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729813#comment-16729813
]
Thorsten Schöning edited comment on MJAVADOC-469 at 12/27/18 8:01 PM:
----------------------------------------------------------------------
In my opinion, the easiest solution is applying the regular expression and
replacement I proposed. That fixes this issue, doesn't seem to break too much
and more complex things can be implemented as really needed. [~basinilya],
what's your opinion about this? You actually created the bug, what would fit
your needs best?
Any more complex things, especially changing the schema and whatever stuff,
wouldn't be used easily anyway, because the containing pom.xml would need to be
migrated. In my case this issue is about a pom.xml from some 3rd party project
that worked on Linux and wasn't ever tested on Windows by the developers, so
failed for me. I'm not even sure if upstream accepted my patch with my
mentioned workaround yet, so they won't likely rewrite their pom.xml to use
newer stuff.
The only good solution is one that works without changing the pom.xml, by
relying only on people which are affected by the problem to simply update their
own Maven. That is something I have control of. If I need to rewrite the
pom.xml anyway, I could simply stick with my documented workaround. If you
think otherwise, [~rfscholte] is correct, simply don't do anything because it
won't help much.
bq. Are you willing to raise an issue with Oracle to at least clarify the
documentation.
I'm not sure who to write at currently, so started a question on SO first:
https://stackoverflow.com/questions/53949999/who-is-responsible-for-docs-and-implementation-of-the-javadoc-tool
was (Author: tschoening):
In my opinion, the easiest solution is applying the regular expression and
replacement I proposed. That fixes this issue, doesn't seem to break too much
and more complex things can be implemented as really needed. [~basinilya],
what's your opinion about this? You actually created the bug, what would fit
you needs easiest?
Any more complex things, especially changing the schema and whatever stuff,
wouldn't be used easily anyway, because the containing pom.xml would need to be
migrated. In my case this issue is about a pom.xml from some 3rd party project
that worked on Linux and wasn't ever tested on Windows by the developers, so
failed for me. I'm not even sure if upstream accepted my patch with my
mentioned workaround yet, so they won't likely rewrite their pom.xml to use
newer stuff.
The only good solution is one that works without changing the pom.xml, by
relying only on people which are affected by the problem to simply update their
own Maven. That is something I have control of. If I need to rewrite the
pom.xml anyway, I could simply stick with my documented workaround. If you
think otherwise, [~rfscholte] is correct, simply don't do anything because it
won't help much.
bq. Are you willing to raise an issue with Oracle to at least clarify the
documentation.
I'm not sure who to write at currently, so started a question on SO first:
https://stackoverflow.com/questions/53949999/who-is-responsible-for-docs-and-implementation-of-the-javadoc-tool
> javadoc-plugin does not double backslashes in argument file
> -----------------------------------------------------------
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
> Affects Versions: 2.10.4
> Reporter: Ilya Basin
> Assignee: Michael Osipov
> Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
