You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Alexander Sack <pi...@gmail.com> on 2008/02/08 21:31:48 UTC
Javadoc plugin bug/issue reprised
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
Re: Javadoc plugin bug/issue reprised
Posted by Stephen Connolly <st...@gmail.com>.
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 <wa...@gmail.com> 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 <pi...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Javadoc plugin bug/issue reprised
Posted by Alexander Sack <pi...@gmail.com>.
Thanks guys, will do this tonight. Arrghh, mvn install, not deploy, I don't
how I got those confused!
-aps
On Feb 11, 2008 5:56 PM, Vincent Siveton <vi...@gmail.com> wrote:
> Hi,
>
> More comments inside...
>
> 2008/2/11, Dennis Lundberg <de...@apache.org>:
> > Alexander Sack wrote:
> > > Hey Vincent:
> > > No problem. I would love to. I have a really really stupid question.
> > >
> > > What I've done is:
> > >
> > > 1) Checked out the 2.0.x trunk
> >
> > This is not necessary, you can use a regular Maven release.
> >
>
> Do a co from
> https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin
>
> Cheers,
>
> Vincent
>
> > > 2) Built a new maven-javadoc-plugin
> > > 3) Used mvn deploy:deploy-file to install it on my test machine
> >
> > To install your version of the plugin into your local repository, use
> > the command instead: mvn install
> >
> > > 4) Change my project's pom file that uses javadoc to include
> <version>
> > > 2.4-SNAPSHOT</version>
> > > 5) Execute mvn site
> > > 6) Stair blankly at the screen as I get the can't fine 2.4-SNAPSHOTmessage
> > >
> > > I've tried using the 2.0.8 stable as well as the bootstrapped
> > > 2.0.9-SNAPSHOTI built with no luck (I've even built offline (-o)). It
> > > can't seem to find
> > > my new javadoc plugin jar file I deployed. I noticed that
> > > deploy:deploy-file on 2.0.8 adds a date as part of the jar file (2.0.4did
> > > not do this). Have snapshot deployment/handling changed? What am I
> doing
> > > wrong?
> > >
> > > Here is my deploy line:
> > >
> > > mvn deploy:deploy-file
> > > -Dversion=2.4-SNAPSHOT-DartifactId=maven-javadoc-plugin -DgroupId=
> > > org.apache.maven.plugins -Dpackaging=jar -Dfile=/root/maven-
> > > javadoc-plugin-2.4-SNAPSHOT.jar -url=file:///root/.m2/repository
> > >
> > > Thanks!
> > >
> > > -aps
> > >
> > > On Feb 11, 2008 7:22 AM, Vincent Siveton <vi...@gmail.com>
> wrote:
> > >
> > >> Alexander,
> > >>
> > >> Please open an issue, and if you want propose a patch :)
> > >> I guess that the pattern used should also work with -J-version
> > >>
> > >> Vincent
> > >>
> > >> 2008/2/10, Alexander Sack <pi...@gmail.com>:
> > >>> Exactly. The use of "-fullversion" is really for internal use as
> per
> > >>> Benjamin and typically the format is "java version <version>" or
> > >> something
> > >>> of that elk which is very easy to parse. Again, I would rely on the
> > >>> javadocVersion tag as a backup.
> > >>> Thanks!
> > >>>
> > >>> -aps
> > >>>
> > >>> On Feb 10, 2008 3:22 PM, Benjamin Bentmann <
> benjamin.bentmann@udo.edu>
> > >>> wrote:
> > >>>
> > >>>>>> Is there any reason again why it can't use "-version?"
> > >>>>>>
> > >>>>> -version gives a lot of unuseful informations.
> > >>>> The unuseful information should not be a problem for the version
> > >> parsing.
> > >>>> On
> > >>>> the other hand, "-fullversion" is "for internal use only" according
> to
> > >> [0]
> > >>>> so it seems wise to switch to "-version" and rely on a
> > >> public/documentated
> > >>>> command line switch.
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>>
> > >>>> Benjamin Bentmann
> > >>>>
> > >>>>
> > >>>> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4127994
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>> "What lies behind us and what lies in front of us is of little
> concern
> > >> to
> > >>> what lies within us." -Ralph Waldo Emerson
> > >>>
> > >
> > >
> > >
> >
> >
> > --
> > Dennis Lundberg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: Javadoc plugin bug/issue reprised
Posted by Vincent Siveton <vi...@gmail.com>.
Hi,
More comments inside...
2008/2/11, Dennis Lundberg <de...@apache.org>:
> Alexander Sack wrote:
> > Hey Vincent:
> > No problem. I would love to. I have a really really stupid question.
> >
> > What I've done is:
> >
> > 1) Checked out the 2.0.x trunk
>
> This is not necessary, you can use a regular Maven release.
>
Do a co from
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin
Cheers,
Vincent
> > 2) Built a new maven-javadoc-plugin
> > 3) Used mvn deploy:deploy-file to install it on my test machine
>
> To install your version of the plugin into your local repository, use
> the command instead: mvn install
>
> > 4) Change my project's pom file that uses javadoc to include <version>
> > 2.4-SNAPSHOT</version>
> > 5) Execute mvn site
> > 6) Stair blankly at the screen as I get the can't fine 2.4-SNAPSHOT message
> >
> > I've tried using the 2.0.8 stable as well as the bootstrapped
> > 2.0.9-SNAPSHOTI built with no luck (I've even built offline (-o)). It
> > can't seem to find
> > my new javadoc plugin jar file I deployed. I noticed that
> > deploy:deploy-file on 2.0.8 adds a date as part of the jar file (2.0.4 did
> > not do this). Have snapshot deployment/handling changed? What am I doing
> > wrong?
> >
> > Here is my deploy line:
> >
> > mvn deploy:deploy-file
> > -Dversion=2.4-SNAPSHOT-DartifactId=maven-javadoc-plugin -DgroupId=
> > org.apache.maven.plugins -Dpackaging=jar -Dfile=/root/maven-
> > javadoc-plugin-2.4-SNAPSHOT.jar -url=file:///root/.m2/repository
> >
> > Thanks!
> >
> > -aps
> >
> > On Feb 11, 2008 7:22 AM, Vincent Siveton <vi...@gmail.com> wrote:
> >
> >> Alexander,
> >>
> >> Please open an issue, and if you want propose a patch :)
> >> I guess that the pattern used should also work with -J-version
> >>
> >> Vincent
> >>
> >> 2008/2/10, Alexander Sack <pi...@gmail.com>:
> >>> Exactly. The use of "-fullversion" is really for internal use as per
> >>> Benjamin and typically the format is "java version <version>" or
> >> something
> >>> of that elk which is very easy to parse. Again, I would rely on the
> >>> javadocVersion tag as a backup.
> >>> Thanks!
> >>>
> >>> -aps
> >>>
> >>> On Feb 10, 2008 3:22 PM, Benjamin Bentmann <be...@udo.edu>
> >>> wrote:
> >>>
> >>>>>> Is there any reason again why it can't use "-version?"
> >>>>>>
> >>>>> -version gives a lot of unuseful informations.
> >>>> The unuseful information should not be a problem for the version
> >> parsing.
> >>>> On
> >>>> the other hand, "-fullversion" is "for internal use only" according to
> >> [0]
> >>>> so it seems wise to switch to "-version" and rely on a
> >> public/documentated
> >>>> command line switch.
> >>>>
> >>>> Regards,
> >>>>
> >>>>
> >>>> Benjamin Bentmann
> >>>>
> >>>>
> >>>> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4127994
> >>>>
> >>>>
> >>>
> >>> --
> >>> "What lies behind us and what lies in front of us is of little concern
> >> to
> >>> what lies within us." -Ralph Waldo Emerson
> >>>
> >
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Javadoc plugin bug/issue reprised
Posted by Dennis Lundberg <de...@apache.org>.
Alexander Sack wrote:
> Hey Vincent:
> No problem. I would love to. I have a really really stupid question.
>
> What I've done is:
>
> 1) Checked out the 2.0.x trunk
This is not necessary, you can use a regular Maven release.
> 2) Built a new maven-javadoc-plugin
> 3) Used mvn deploy:deploy-file to install it on my test machine
To install your version of the plugin into your local repository, use
the command instead: mvn install
> 4) Change my project's pom file that uses javadoc to include <version>
> 2.4-SNAPSHOT</version>
> 5) Execute mvn site
> 6) Stair blankly at the screen as I get the can't fine 2.4-SNAPSHOT message
>
> I've tried using the 2.0.8 stable as well as the bootstrapped
> 2.0.9-SNAPSHOTI built with no luck (I've even built offline (-o)). It
> can't seem to find
> my new javadoc plugin jar file I deployed. I noticed that
> deploy:deploy-file on 2.0.8 adds a date as part of the jar file (2.0.4 did
> not do this). Have snapshot deployment/handling changed? What am I doing
> wrong?
>
> Here is my deploy line:
>
> mvn deploy:deploy-file
> -Dversion=2.4-SNAPSHOT-DartifactId=maven-javadoc-plugin -DgroupId=
> org.apache.maven.plugins -Dpackaging=jar -Dfile=/root/maven-
> javadoc-plugin-2.4-SNAPSHOT.jar -url=file:///root/.m2/repository
>
> Thanks!
>
> -aps
>
> On Feb 11, 2008 7:22 AM, Vincent Siveton <vi...@gmail.com> wrote:
>
>> Alexander,
>>
>> Please open an issue, and if you want propose a patch :)
>> I guess that the pattern used should also work with -J-version
>>
>> Vincent
>>
>> 2008/2/10, Alexander Sack <pi...@gmail.com>:
>>> Exactly. The use of "-fullversion" is really for internal use as per
>>> Benjamin and typically the format is "java version <version>" or
>> something
>>> of that elk which is very easy to parse. Again, I would rely on the
>>> javadocVersion tag as a backup.
>>> Thanks!
>>>
>>> -aps
>>>
>>> On Feb 10, 2008 3:22 PM, Benjamin Bentmann <be...@udo.edu>
>>> wrote:
>>>
>>>>>> Is there any reason again why it can't use "-version?"
>>>>>>
>>>>> -version gives a lot of unuseful informations.
>>>> The unuseful information should not be a problem for the version
>> parsing.
>>>> On
>>>> the other hand, "-fullversion" is "for internal use only" according to
>> [0]
>>>> so it seems wise to switch to "-version" and rely on a
>> public/documentated
>>>> command line switch.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Benjamin Bentmann
>>>>
>>>>
>>>> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4127994
>>>>
>>>>
>>>
>>> --
>>> "What lies behind us and what lies in front of us is of little concern
>> to
>>> what lies within us." -Ralph Waldo Emerson
>>>
>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Javadoc plugin bug/issue reprised
Posted by Alexander Sack <pi...@gmail.com>.
Hey Vincent:
No problem. I would love to. I have a really really stupid question.
What I've done is:
1) Checked out the 2.0.x trunk
2) Built a new maven-javadoc-plugin
3) Used mvn deploy:deploy-file to install it on my test machine
4) Change my project's pom file that uses javadoc to include <version>
2.4-SNAPSHOT</version>
5) Execute mvn site
6) Stair blankly at the screen as I get the can't fine 2.4-SNAPSHOT message
I've tried using the 2.0.8 stable as well as the bootstrapped
2.0.9-SNAPSHOTI built with no luck (I've even built offline (-o)). It
can't seem to find
my new javadoc plugin jar file I deployed. I noticed that
deploy:deploy-file on 2.0.8 adds a date as part of the jar file (2.0.4 did
not do this). Have snapshot deployment/handling changed? What am I doing
wrong?
Here is my deploy line:
mvn deploy:deploy-file
-Dversion=2.4-SNAPSHOT-DartifactId=maven-javadoc-plugin -DgroupId=
org.apache.maven.plugins -Dpackaging=jar -Dfile=/root/maven-
javadoc-plugin-2.4-SNAPSHOT.jar -url=file:///root/.m2/repository
Thanks!
-aps
On Feb 11, 2008 7:22 AM, Vincent Siveton <vi...@gmail.com> wrote:
> Alexander,
>
> Please open an issue, and if you want propose a patch :)
> I guess that the pattern used should also work with -J-version
>
> Vincent
>
> 2008/2/10, Alexander Sack <pi...@gmail.com>:
> > Exactly. The use of "-fullversion" is really for internal use as per
> > Benjamin and typically the format is "java version <version>" or
> something
> > of that elk which is very easy to parse. Again, I would rely on the
> > javadocVersion tag as a backup.
> > Thanks!
> >
> > -aps
> >
> > On Feb 10, 2008 3:22 PM, Benjamin Bentmann <be...@udo.edu>
> > wrote:
> >
> > > >> Is there any reason again why it can't use "-version?"
> > > >>
> > > >
> > > > -version gives a lot of unuseful informations.
> > >
> > > The unuseful information should not be a problem for the version
> parsing.
> > > On
> > > the other hand, "-fullversion" is "for internal use only" according to
> [0]
> > > so it seems wise to switch to "-version" and rely on a
> public/documentated
> > > command line switch.
> > >
> > > Regards,
> > >
> > >
> > > Benjamin Bentmann
> > >
> > >
> > > [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4127994
> > >
> > >
> >
> >
> > --
> > "What lies behind us and what lies in front of us is of little concern
> to
> > what lies within us." -Ralph Waldo Emerson
> >
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: Javadoc plugin bug/issue reprised
Posted by Vincent Siveton <vi...@gmail.com>.
Alexander,
Please open an issue, and if you want propose a patch :)
I guess that the pattern used should also work with -J-version
Vincent
2008/2/10, Alexander Sack <pi...@gmail.com>:
> Exactly. The use of "-fullversion" is really for internal use as per
> Benjamin and typically the format is "java version <version>" or something
> of that elk which is very easy to parse. Again, I would rely on the
> javadocVersion tag as a backup.
> Thanks!
>
> -aps
>
> On Feb 10, 2008 3:22 PM, Benjamin Bentmann <be...@udo.edu>
> wrote:
>
> > >> Is there any reason again why it can't use "-version?"
> > >>
> > >
> > > -version gives a lot of unuseful informations.
> >
> > The unuseful information should not be a problem for the version parsing.
> > On
> > the other hand, "-fullversion" is "for internal use only" according to [0]
> > so it seems wise to switch to "-version" and rely on a public/documentated
> > command line switch.
> >
> > Regards,
> >
> >
> > Benjamin Bentmann
> >
> >
> > [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4127994
> >
> >
>
>
> --
> "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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Javadoc plugin bug/issue reprised
Posted by Alexander Sack <pi...@gmail.com>.
Exactly. The use of "-fullversion" is really for internal use as per
Benjamin and typically the format is "java version <version>" or something
of that elk which is very easy to parse. Again, I would rely on the
javadocVersion tag as a backup.
Thanks!
-aps
On Feb 10, 2008 3:22 PM, Benjamin Bentmann <be...@udo.edu>
wrote:
> >> Is there any reason again why it can't use "-version?"
> >>
> >
> > -version gives a lot of unuseful informations.
>
> The unuseful information should not be a problem for the version parsing.
> On
> the other hand, "-fullversion" is "for internal use only" according to [0]
> so it seems wise to switch to "-version" and rely on a public/documentated
> command line switch.
>
> Regards,
>
>
> Benjamin Bentmann
>
>
> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4127994
>
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: Javadoc plugin bug/issue reprised
Posted by Benjamin Bentmann <be...@udo.edu>.
>> Is there any reason again why it can't use "-version?"
>>
>
> -version gives a lot of unuseful informations.
The unuseful information should not be a problem for the version parsing. On
the other hand, "-fullversion" is "for internal use only" according to [0]
so it seems wise to switch to "-version" and rely on a public/documentated
command line switch.
Regards,
Benjamin Bentmann
[0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4127994
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Javadoc plugin bug/issue reprised
Posted by Vincent Siveton <vi...@gmail.com>.
2008/2/10, Alexander Sack <pi...@gmail.com>:
> 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 <wa...@gmail.com> 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 <pi...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> "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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Javadoc plugin bug/issue reprised
Posted by Alexander Sack <pi...@gmail.com>.
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 <wa...@gmail.com> 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 <pi...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: Javadoc plugin bug/issue reprised
Posted by Wayne Fay <wa...@gmail.com>.
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 <pi...@gmail.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org