Hi Wayne/Devlist: I guess this should be on the developers list so I'm switching gears (please include my email in any response since I'm not on the dev list yet):
When the javadoc plugin attempts to grab the javadoc binaries version in the JavadocUtil.getJavadocVersion() it attempts to execute: javadoc -J-fullversion instead of javadoc -J-version -fullversion will return various things depending on platform implementation of java. After looking a the source for little I really don't see an obvious reason why "-version" shouldn't be used? i.e. I think all you need to know is the Java version number like 1.5 or 1.4 (the comparo's in the mojo are just looking at version numbers, not platform types). On one particular machine which uses SCO Unix, javadoc -J-fullversion returns: SCO-UNIX-J2SE-1.5.0_09*FCS-UW714-OSR6*_20061114 The pattern matching in JavadocUtil.parseJavadocVersion() is not returning a string that can be parsed into a float and as such I see a NumberFormatException when I execute the site goal as part of the build lifecycle. Is there any reason again why it can't use "-version?" (I believe that simple change would fix my immediate problem) Moreover, another potential bug is that in executeReport() of the javadoc mojo, it is first going to grab the version from executing javadoc and trying to match that with the configuration doc <javadocVersion>. I think if you can't parse the javadoc version, then just default to whatever the tag says (a fail safe solution). So perhaps the NumberformatException could be caught, return null from the parseJavadocVersion() and then see if a <javadocVersion> was specified and use that. Otherwise, bail. I can submit a patch if people feel my summary is correct. This is the first time I'm looking at Maven source! :D! So far that's my analysis of the situation. Comments welcomed and thanks, -aps On Feb 8, 2008 6:09 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > If you're reasonably certain you've found a bug (and it sounds like > you have), and have a work-around/better solution, then please do file > a JIRA bug and attach your patch. > > I have no idea why it is using java.vm.version rather than > java.version, but I'd assume there's a reason. Perhaps your patch > could read from both, and then pick the best fitting VM out of the 2 > property strings. > > Wayne > > On 2/8/08, Alexander Sack <[EMAIL PROTECTED]> wrote: > > So I figured out the issue and I was wondering if I could get a little > > guidance. The javadoc plugin when it executes the javadoc:javadoc goal > > attempts to determine the version of the VM its running. I suspect its > > parsing the java.vm.version string. On the platform I'm on, that is > > different than the expected 1.5.x etc. format. Its actually > > OS-VERSION-VMVERSION format which causes a NumberFormatException when > > javadoc is ran the plugin. > > Is there any reason why it isn't using the java.version System property > > instead which is more generic across different Java implementations? I > had > > a very similar issue with another plugin (native2ascii) that was > assuming > > certain things about the platform. > > > > Any guidance would be appreciated, > > > > -aps > > > > -- > > "What lies behind us and what lies in front of us is of little concern > to > > what lies within us." -Ralph Waldo Emerson > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson
