[jira] Created: (DOXIA-397) Cannot link to javadoc methods
Cannot link to javadoc methods
--
Key: DOXIA-397
URL: http://jira.codehaus.org/browse/DOXIA-397
Project: Maven Doxia
Issue Type: Bug
Components: Core, Module - Apt, Module - Xdoc
Affects Versions: 1.1.3
Reporter: Lukas Theussl
Using a link to a javadoc method like
{noformat}
{{{../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)}ParserRegistry}}
{noformat}
the apt parser removes the brackets of the anchor. The same thing happens with
xdocs and probably other formats. Note that non-ascii characters are not legal
in anchor names, but they should be replaced by their hex values, see
http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-397) Cannot link to javadoc methods
[
http://jira.codehaus.org/browse/DOXIA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226334#action_226334
]
Thom Nichols commented on DOXIA-397:
It also removes commas (which are unescaped in JavaDoc links) and
already-escaped octets lose the '%'. So pre-escaping non-alphanumeric
characters doesn't help in this case.
So
{code}
{{{../apidocs/groovyx/net/http/HTTPBuilder.html#get%28java.util.Map,%20groovy.lang.Closure%29}get()}}>>>
{code}
becomes
{code}
get()
{code}
> Cannot link to javadoc methods
> --
>
> Key: DOXIA-397
> URL: http://jira.codehaus.org/browse/DOXIA-397
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Apt, Module - Xdoc
>Affects Versions: 1.1.3
>Reporter: Lukas Theussl
>
> Using a link to a javadoc method like
> {noformat}
> {{{../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)}ParserRegistry}}
> {noformat}
> the apt parser removes the brackets of the anchor. The same thing happens
> with xdocs and probably other formats. Note that non-ascii characters are not
> legal in anchor names, but they should be replaced by their hex values, see
> http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-397) Cannot link to javadoc methods
[
http://jira.codehaus.org/browse/DOXIA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226338#action_226338
]
Lukas Theussl commented on DOXIA-397:
-
I was about to commit a fix when I saw your example above and realized that it
won't work for more than one argument. The problem is the space after the
comma, which doxia replaces by an underscore, instead of its hex value
(http://maven.apache.org/doxia/doxia/doxia-core/apidocs/org/apache/maven/doxia/util/DoxiaUtils.html#encodeId%28java.lang.String,%20boolean%29
).
The reason for this choice of replacement, I think, was to generate readable
links for the most typical use-case of anchors in apt documents, eg links to
section titles, etc. I'm afraid we will break a lot of stuff if we change this
now.
> Cannot link to javadoc methods
> --
>
> Key: DOXIA-397
> URL: http://jira.codehaus.org/browse/DOXIA-397
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Apt, Module - Xdoc
>Affects Versions: 1.1.3
>Reporter: Lukas Theussl
>
> Using a link to a javadoc method like
> {noformat}
> {{{../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)}ParserRegistry}}
> {noformat}
> the apt parser removes the brackets of the anchor. The same thing happens
> with xdocs and probably other formats. Note that non-ascii characters are not
> legal in anchor names, but they should be replaced by their hex values, see
> http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-397) Cannot link to javadoc methods
[
http://jira.codehaus.org/browse/DOXIA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226339#action_226339
]
Thom Nichols commented on DOXIA-397:
So the behavior, if I understand correctly, relates to what's described here:
http://maven.apache.org/doxia/references/doxia-apt.html#Links
Specifically, Doxia is parsing 'local' links as if they are 'anchors' (or
'internal links'?)
If Doxia sees a link that starts with './' or '../', should it be manipulating
it at all? I thought a local link had to be a valid URI fragment?
> Cannot link to javadoc methods
> --
>
> Key: DOXIA-397
> URL: http://jira.codehaus.org/browse/DOXIA-397
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Apt, Module - Xdoc
>Affects Versions: 1.1.3
>Reporter: Lukas Theussl
>
> Using a link to a javadoc method like
> {noformat}
> {{{../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)}ParserRegistry}}
> {noformat}
> the apt parser removes the brackets of the anchor. The same thing happens
> with xdocs and probably other formats. Note that non-ascii characters are not
> legal in anchor names, but they should be replaced by their hex values, see
> http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-397) Cannot link to javadoc methods
[
http://jira.codehaus.org/browse/DOXIA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226342#action_226342
]
Lukas Theussl commented on DOXIA-397:
-
Not really, this issue has nothing to do with local, internal or external
links. These notions only distinguish the case of where the link points to
(target within same source document, target within same site, target outside),
but in each case the URI has to be valid. Since Doxia 1.1 we fix all invalid
ids, that's why the warning is emitted, you are supposed to correct the links
in your source documents.
Btw, it should work if you use absolute links, as only local and internal links
are re-written. Eg if you link from one apt document to another within your
site, you can control both the link (href) and the target (anchor), but if you
link to the internet, you usually do not control the target. Unfortunately,
javadoc generates invalid anchors, which is apparently a well-known fact:
http://mindprod.com/jgloss/javadoc.html
> Cannot link to javadoc methods
> --
>
> Key: DOXIA-397
> URL: http://jira.codehaus.org/browse/DOXIA-397
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Apt, Module - Xdoc
>Affects Versions: 1.1.3
>Reporter: Lukas Theussl
>
> Using a link to a javadoc method like
> {noformat}
> {{{../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)}ParserRegistry}}
> {noformat}
> the apt parser removes the brackets of the anchor. The same thing happens
> with xdocs and probably other formats. Note that non-ascii characters are not
> legal in anchor names, but they should be replaced by their hex values, see
> http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (DOXIA-397) Cannot link to javadoc methods
[
http://jira.codehaus.org/browse/DOXIA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226342#action_226342
]
Lukas Theussl edited comment on DOXIA-397 at 6/25/10 9:14 AM:
--
Not really, this issue has nothing to do with local, internal or external
links. These notions only distinguish the case of where the link points to
(target within same source document, target within same site, target outside),
but in each case the URI has to be valid. Since Doxia 1.1 we fix all invalid
ids, that's why the warning is emitted, you are supposed to correct the links
in your source documents.
Btw, it should work if you use absolute links, as only local and internal links
are re-written. Eg if you link from one apt document to another within your
site, you can control both the link (href) and the target (anchor), but if you
link to the internet, you usually do not control the target. Unfortunately,
javadoc generates invalid anchors, which is apparently a well-known fact:
http://mindprod.com/jgloss/javadoc.html#BUGS
was (Author: lukas):
Not really, this issue has nothing to do with local, internal or external
links. These notions only distinguish the case of where the link points to
(target within same source document, target within same site, target outside),
but in each case the URI has to be valid. Since Doxia 1.1 we fix all invalid
ids, that's why the warning is emitted, you are supposed to correct the links
in your source documents.
Btw, it should work if you use absolute links, as only local and internal links
are re-written. Eg if you link from one apt document to another within your
site, you can control both the link (href) and the target (anchor), but if you
link to the internet, you usually do not control the target. Unfortunately,
javadoc generates invalid anchors, which is apparently a well-known fact:
http://mindprod.com/jgloss/javadoc.html
> Cannot link to javadoc methods
> --
>
> Key: DOXIA-397
> URL: http://jira.codehaus.org/browse/DOXIA-397
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Apt, Module - Xdoc
>Affects Versions: 1.1.3
>Reporter: Lukas Theussl
>
> Using a link to a javadoc method like
> {noformat}
> {{{../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)}ParserRegistry}}
> {noformat}
> the apt parser removes the brackets of the anchor. The same thing happens
> with xdocs and probably other formats. Note that non-ascii characters are not
> legal in anchor names, but they should be replaced by their hex values, see
> http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-489) Failure to locate component descriptors in another project
Failure to locate component descriptors in another project
--
Key: MASSEMBLY-489
URL: http://jira.codehaus.org/browse/MASSEMBLY-489
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-5
Environment: Apache Maven 3.0-beta-1 (r935667; 2010-04-19
19:00:39+0200)
Java version: 1.6.0_20
Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre
Default locale: en_CA, platform encoding: UTF-8
OS name: "linux" version: "2.6.31-22-generic" arch: "i386" Family: "unix"
Reporter: Andreas Sewe
Attachments: aggregator.tar.gz
The {{maven-assembly-plugin}} seems to search for component descriptors in the
current project instead of in the one containing the assembly descriptors which
do the referring. This behavior is probably a bug and makes it quite impossible
to use such a modularized assembly descriptor from a different project.
The attached multi-module project exemplifies this; just run "mvn install" from
the aggregator project and you will get the following stack trace:
{quote}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single (default) on
project problematic-module: Error reading assemblies: Failed to locate
component descriptor: src/main/resources/assemblies/component.xml
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:141)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:190)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:246)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:95)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:430)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:160)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error reading
assemblies: Failed to locate component descriptor:
src/main/resources/assemblies/component.xml
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:356)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133)
... 19 more
Caused by: org.apache.maven.plugin.assembly.io.AssemblyReadException: Failed to
locate component descriptor: src/main/resources/assemblies/component.xml
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.mergeComponentsWithMainAssembly(DefaultAssemblyReader.java:452)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssembly(DefaultAssemblyReader.java:366)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyForDescriptorReference(DefaultAssemblyReader.java:257)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:149)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:352)
... 21 more
[ERROR]
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-397) Cannot link to javadoc methods
[
http://jira.codehaus.org/browse/DOXIA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226359#action_226359
]
Thom Nichols commented on DOXIA-397:
So you can have a link to a 'local' Doxia ID that's not on the same page? I
assumed local links had to be valid relative URIs.
It sounds like the proper solution would be to have two link formats - one for
URIs and one for Doxia IDs. Otherwise, how can Doxia tell if this:
{code}
{{{../apidocs/groovyx/net/http/HTTPBuilder.html#defaultSuccessHandler%28org.apache.http.HttpResponse%2C%20java.lang.Object%29}defaultSuccessHandler}}
{code}
is a Doxia ID or a relative URI?
> Cannot link to javadoc methods
> --
>
> Key: DOXIA-397
> URL: http://jira.codehaus.org/browse/DOXIA-397
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Apt, Module - Xdoc
>Affects Versions: 1.1.3
>Reporter: Lukas Theussl
>
> Using a link to a javadoc method like
> {noformat}
> {{{../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)}ParserRegistry}}
> {noformat}
> the apt parser removes the brackets of the anchor. The same thing happens
> with xdocs and probably other formats. Note that non-ascii characters are not
> legal in anchor names, but they should be replaced by their hex values, see
> http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-397) Cannot link to javadoc methods
[
http://jira.codehaus.org/browse/DOXIA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226360#action_226360
]
Thom Nichols commented on DOXIA-397:
Or, if it's not a valid Doxia ID, just complain (emit a warning message) but
don't munge it.
But maybe some people are relying on behavior to turn {{{Some Section
Heading}blah}} into blah
> Cannot link to javadoc methods
> --
>
> Key: DOXIA-397
> URL: http://jira.codehaus.org/browse/DOXIA-397
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Apt, Module - Xdoc
>Affects Versions: 1.1.3
>Reporter: Lukas Theussl
>
> Using a link to a javadoc method like
> {noformat}
> {{{../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)}ParserRegistry}}
> {noformat}
> the apt parser removes the brackets of the anchor. The same thing happens
> with xdocs and probably other formats. Note that non-ascii characters are not
> legal in anchor names, but they should be replaced by their hex values, see
> http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
