2008/2/10, Alexander Sack <[EMAIL PROTECTED]>: > 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 >
This was already fixed in the trunk. I just added a test case with this given version (r620316) [1] > 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?" > -version gives a lot of unuseful informations. > (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. > The user *should* specify the javadocVersion in the right format. If not, an exception is thrown. > I can submit a patch if people feel my summary is correct. This is the > first time I'm looking at Maven source! :D! > All patches are always welcome!. Before just have a glance to [2] and [3] Cheers, Vincent [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin [2] http://jira.codehaus.org/browse/MJAVADOC [3] http://maven.apache.org/guides/development/guide-helping.html > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
