[jira] (SUREFIRE-131) Excluding tests with command line pattern
[
https://jira.codehaus.org/browse/SUREFIRE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353821#comment-353821
]
Valters Vingolds commented on SUREFIRE-131:
---
This would really be helpful for skipping a test on CI environment, where it is
known to work erratically. (For example, E2E test that is flaky, and we don't
want it invalidating the whole staging build.)
The key is we don't want to modify a pom.xml file, it should be done via
command line option.
Excluding tests with command line pattern
-
Key: SUREFIRE-131
URL: https://jira.codehaus.org/browse/SUREFIRE-131
Project: Maven Surefire
Issue Type: New Feature
Components: Maven Surefire Plugin
Affects Versions: 2.0 (2.2 plugin)
Environment: All environments running JUnit tests
Reporter: Johannes Carlén
Priority: Minor
Fix For: Backlog
I'd like to be able to exclude certain tests from being run. An example of
this could be a scenario where I'd like just the unit tests and not the
integration tests to run. In our case, we name all integration test with the
postfix IntTest instead of just Test.
This is now possible through configuring the plugin in the pom, however it is
not possible to decide at the command line if I just like to run some tests
and not all.
Example of use with this implementation would be:
mvn -Dexclude=*IntTest test
which would run all tests - excluding those that ends with IntTest
The amount of code needed for implementation is minimal. In
SurefirePlugin.java:
Just add a property - something like:
/**
* Specify this parameter to exclude test by their name. It follows
* the same conventions as the codetest/code parameter.
*
* @parameter expression=${exclude}
*
*/
private String exclude;
Add this code at line 527
if ( this.exclude != null )
{
String exclude = **/ + this.exclude + .java;
excludes.add(exclude);
getLog().debug( Excluding test with pattern : + exclude
);
}
...and that's all.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIA-470) Conflence: support [jira-ticket@jira] construct
Valters Vingolds created DOXIA-470:
--
Summary: Conflence: support [jira-ticket@jira] construct
Key: DOXIA-470
URL: https://jira.codehaus.org/browse/DOXIA-470
Project: Maven Doxia
Issue Type: New Feature
Reporter: Valters Vingolds
Priority: Minor
In Confluence Wiki, it is possible to link to Jira tickets with format
{{[DOXIA-293@jira]}}, because the Wiki also knows the Jira server location.
It's very useful. I'd like to see support in Doxia for this too.
The @jira signals to parser to get the location of JIRA server (configured
somewhere, http://(jira...)/browse/) and append the ticket identifier. The
information needs to come from maven-site-plugin.
I feel this would be similar story to support javadoc location macro
DOXIA-293.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valters Vingolds updated DOXIA-467:
---
Attachment: confluence-escaping-patch-files.zip
confluence-escaping-hg.patch
I am attaching updated version of patch (mercurial format, I imported source to
private hg repo to produce acceptable patch, and not lose track of other
changes I am experimenting with).
Also attaching the changed files, incase it is simply easier for you to use
some DiffMerge visual tool.
This patch also handles following markup correctly:
{code}
{{monospaced $\{with.escaped.variable\}}}
{code}
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds commented on DOXIA-467:
Ok, with llowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 10:56 AM:
-
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block.
was (Author: valters):
Ok, with llowing to escape { via \, now there is issue with markup like
this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 11:00 AM:
-
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 1:50 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the greedy (but Confluence
does not match them greedy)
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 1:51 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the {{monospace}}} greedy (but
Confluence Wiki does not match them greedy)
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the greedy (but Confluence
does not match them greedy)
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 1:51 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the {{monospace}}} greedy (but
Confluence Wiki does not match them greedy)
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 1:52 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the previous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 3:45 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
than idea to include links in monospace blocks.
For the previous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the previous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-471) Confluence: should output page title (sink.title(), title_())
Valters Vingolds created DOXIA-471: -- Summary: Confluence: should output page title (sink.title(), title_()) Key: DOXIA-471 URL: https://jira.codehaus.org/browse/DOXIA-471 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Reporter: Valters Vingolds With DOXIASITETOOLS-70 the page title is constructed as (Site title) - (Page title). So having a nicely constructed page title is ever important. Unfortunately the Confluence module actually does not provide the page title to sink ever (understandably so - because with confluence page we don't really know what the page title should be). We need to come up with some idea what could be used as page title. I would like to propose to catch first h1. header (or any first section header), and just register that as page title. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
Valters Vingolds created DOXIA-467:
--
Summary: Confluence: Inconsistent handling of '\' escape
characters, incorrect handling of \\ inside {{monospace}} blocks.
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to escape
them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't yet
looked how feasible it is to make \\ only work as line break if it appears at
the end of line, but my requirement was simpler: to make \\ work inside
{{monospace}} blocks, i.e., make it appear verbatim, and not produce linebreak.
So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen to
have a lot of code variables that use underscore (variables_like_this), and
currently the underscores get eaten, and (like) part gets italicized. (Escaping
all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized but
something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA parses
this text according to Confluence rules. We should strive to replicate this
behaviour, as I see one use-case of this module is to transfer wiki pages
created in Confluence into source tree as documentation. That does not work if
our implementation does not faithfully render markup as Confluence wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to remove
them. So if you already applied that patch, you will get some rejected hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300171#comment-300171
]
Valters Vingolds commented on DOXIA-467:
I see that Confluence actually does support \ \ line breaks inline, but with
some clever rules to avoid breaking \\unc\path case, it appears.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300171#comment-300171
]
Valters Vingolds edited comment on DOXIA-467 at 6/1/12 2:36 AM:
I see that Confluence actually does support \ \ line breaks inline, but with
some clever rules to avoid breaking \\unc\path case, it appears. Where there
appear undue line breaks, please read as \ \ :)
was (Author: valters):
I see that Confluence actually does support \ \ line breaks inline, but
with some clever rules to avoid breaking \\unc\path case, it appears.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-298) Confluence: Problem with relative links
[ https://jira.codehaus.org/browse/DOXIA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300128#comment-300128 ] Valters Vingolds commented on DOXIA-298: It seems this patch breaks possibility to link to a file, because .html is now appended to all links. I can't link to .pdf file for example. Confluence: Problem with relative links --- Key: DOXIA-298 URL: https://jira.codehaus.org/browse/DOXIA-298 Project: Maven Doxia Issue Type: Improvement Components: Module - Confluence Affects Versions: 1.1 Reporter: Kornel Assignee: Lukas Theussl Fix For: 1.1.1 Attachments: MNG-298-module-confluence.patch, MNG-298-module-confluence.patch Relative links, for example [Overview|overview/index] are not generated correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-466) confluence: can't create links to non-html resources (like .pdf of .xls files) because .html is always appended
Valters Vingolds created DOXIA-466: -- Summary: confluence: can't create links to non-html resources (like .pdf of .xls files) because .html is always appended Key: DOXIA-466 URL: https://jira.codehaus.org/browse/DOXIA-466 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.3 Reporter: Valters Vingolds Attachments: confluence-resource-links.patch Currently when trying to create link to (for example) resource.pdf file, the link is lways generated as resource.pdf.html. This seems to be a regression introduced by DOXIA-298 anchors handling. As workaround, I propose to use the Confluence's attached files [^resource.file] syntax. If ^ is in front of link, treat link as verbatim. Attaching the patch implementing this proposal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
