Have you got multiple Java VM's installed on your system. We had one developer who had multiple VM's installed and had a CLASSPATH environment variable that pointed to a different JVM than the one he was running Maven from, which caused problems with Javadoc.
The solution was to clear his CLASSPATH environment variable On Feb 8, 2008 11: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] > >
