Bug 17281 - jar2xml does not apply JavaDoc parameter names for static, abstract, or override methods
Summary: jar2xml does not apply JavaDoc parameter names for static, abstract, or overr...
Status: RESOLVED INVALID
Alias: None
Product: Android
Classification: Xamarin
Component: Bindings ()
Version: 4.10.1
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Atsushi Eno
URL:
Depends on:
Blocks:
 
Reported: 2014-01-16 16:03 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2014-12-02 14:13 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED INVALID

Description Brendan Zagaeski (Xamarin Team, assistant) 2014-01-16 16:03:10 UTC
Reported on behalf of a user.

## Steps to reproduce
1. Unzip attached test case.
2. `cd` into the project directory.
3. Run xbuild or MSBuild.


## Result
The <JavaDocPaths> element in the .csproj works, but only partially. In both the `api.xml` file and the generated .cs files in `obj/Debug/generated/src`, all the methods that are _not_ marked `static`, `abstract`, or `override` have named parameters. All the methods that _are_ marked with any of those modifiers have unnamed "p0, p1" parameters.


For example, the OnReceive method in PebbleAckReceiver has unnamed parameters:
> public override void OnReceive (global::Android.Content.Context p0, global::Android.Content.Intent p1)


## Expected result
All the parameters for `static`, `abstract`, and `override` methods can be named according to the javadocs. Note that the `javadocs` folder in the test case contains names for all of the parameters.


Thanks!
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2014-01-17 16:44:32 UTC
In case it might be helpful, the source code for the Java library that's used in the test case can be found here:
> https://github.com/pebble/pebblekit/tree/master/Android/PebbleKit
Comment 3 Atsushi Eno 2014-02-04 10:03:22 UTC
Finally I found the cause of the problem. The type names are not fully qualified with namespaces for some reason, which is wrong (at least unexpected). For example, the Javadoc contains such documentation section for PebbleKit.PebbleAckReceiver.onReceive() as:

<TD><CODE><B><A HREF="../../../../com/getpebble/android/kit/PebbleKit.PebbleAckReceiver.html#onReceive(Context, Intent)">onReceive</A></B>(Context&nbsp;context,
          Intent&nbsp;intent)</CODE>

We try to capture that part with the following regular expression:

<TD><CODE><B><A HREF="[./]*com/getpebble/android/kit/PebbleKit.PebbleAckReceiver.html#onReceive\(\Qandroid.content.Context, android.content.Intent\E\)".*\((.*)\)

which fails because the source document lacks "android.content." parts.

How is that Javadoc generated? If that's really valid documentation and javadoc somehow gives wrong outputs, then that will be likely a limitation for Javadoc import feature.
Comment 4 Jon Dick 2014-12-02 14:13:29 UTC
To add to this issue, I too was experiencing (with javadoc 7) that javadocs were created without the fully qualified type names in the parameters so jar2xml wasn't matching the methods.

The reason in my case, and may be in this other case is that javadoc was not run with the right -classpath args, so it could not resolve all of the types and therefore was not printing their fully qualified names.

Once I specified -classpath /path/to/android.jar I got the fully qualified names generated.