[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729567#comment-16729567
]
Thorsten Schöning edited comment on MJAVADOC-469 at 12/27/18 12:30 PM:
-----------------------------------------------------------------------
bq. Oracle's lack of documentation is just frustrating.
One might argue that they intentionally removed mentioning backslash as escape
character, which might be an argument to really not change anything at all. :-)
But as your test shows, it seems the former behaviour is still there and they
simply refactored the docs: My URL contained Windows-specific parts where the
new docs contain Windows and others at the same page, while still using the
same wrong examples they used before:
bq. -overview \java\jdk9\docs\api\overview-summary.html
https://docs.oracle.com/en/java/javase/11/javadoc/javadoc-command.html#GUID-EFE927BC-DB00-4876-808C-ED23E1AAEF7D
If that would work in an argument file, this ticket wouldn't exist. :-) They
simply Copy&Pasted not carefully enough parts of the old docs, so the hint for
2 backslash got lost I guess.
bq. [~tschoening], your actual proposal is to unconditionally escape
backslashes?
No, my former text wasn't clear because JIRA interpretes my examples specially:
We have two conditions, 2 backslashes directly one after another can be assumed
properly escaped and the combination of 1 backlsash directly followed by a
colon as well. All other single backslashes could be seen as not properly
escaped in my opinion. Something like the following regular expression:
{code:java}
(?<!\\)\\(?!\\|:)
additionalOption = additionalOption.replaceAll("(?<!\\\\)\\\\(?!\\\\|:)",
"\\\\");
{code}
https://regex101.com/r/0e0vs4/1
That doesn't deal with wrong number of backslashes in general, but it seems to
handle the two cases that only 1 backslash is used for a path and that a
workaround like mine is applied already without breaking things. In my opinion
everything else can be kept as is, because things like quoting weren't a
problem in this ticket and that way things shouldn't break which worked before
for some reason.
The only question is if the Maven plugin can make single backslashed paths work
in an options file without breaking too much else.
was (Author: tschoening):
bq. Oracle's lack of documentation is just frustrating.
One might argue that they intentionally removed mentioning backslash as escape
character, which might be an argument to really not change anything at all. :-)
But as your test shows, it seems the former behaviour is still there and they
simply refactored the docs: My URL contained Windows-specific parts where the
new docs contain Windows and others at the same page, while still using the
same wrong examples they used before:
bq. -overview \java\jdk9\docs\api\overview-summary.html
https://docs.oracle.com/en/java/javase/11/javadoc/javadoc-command.html#GUID-EFE927BC-DB00-4876-808C-ED23E1AAEF7D
If that would work in an argument file, this ticket wouldn't exist. :-) They
simply Copy&Pasted not carefully enough parts of the old docs, so the hint for
2 backslash got lost I guess.
bq. [~tschoening], your actual proposal is to unconditionally escape
backslashes?
No, my former text wasn't clear because JIRA interpretes my examples specially:
We have two conditions, 2 backslashes directly one after another can be assumed
properly escaped and the combination of 1 backlsash directly followed by a
colon as well. All other single backslashes could be seen as not properly
escaped in my opinion. Something like the following regular expression:
{code:java}
(?<!\\)\\(?!\\|:)
additionalOption = additionalOption.replaceAll("(?<!\\\\)\\\\(?!\\\\|:)",
"\\\\");
{code}
https://regex101.com/r/0e0vs4/1
That doesn't deal with wrong number of backslashes in general, but it seems to
handle the two cases that only 1 backslash is used for a path and that a
workaround like mine is applied already without breaking things. In my opinion
everything else can be kept as is, because things like quoting weren't a
problem in this ticket and that way things shouldn't break which worked before
for some reason.
The only question is if the Maven plugin can make single backslashed paths work
without breaking too much else.
> 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)
